(19) 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



(12) 



(43) Date of publication: 

05.09.2001 Bulletin 2001/36 

(21) Application number: 01300672.1 

(22) Date of filing: 25.01 .2001 



(11) EP1 130 511 A2 

EUROPEAN PATENT APPLICATION 

(51) lntCI7: G 06 F 9/46 



(84) 


Designated Contracting States: 


(71) 


Applicant: FuslonOne, Inc. 




AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 




San Jose, California 951 13 (US) 




MC NL PTSETR 








Designated Extension States: 


(72) 


Inventor: Mutter, David L. 




AL LT LV MK RO SI 




Santa Cruz, California 95060 (US) 


(30) 


Priority: 25.01.2000 US 490550 


(74) 


Representative: Butler, Michael John 




26.01.2000 US 491675 




Frank B. Delin & Co., 




26.01.2000 US 491694 




European Patent Attorneys, 








179 Queen Victoria Street 








London EC4V 4EL (GB) 



< 



o 

CO 



Q. 

UJ 



(54) Data transfer and synchronization system 

(57) A system and method for synchronizing devic- 
es which can couple to the internet, or any network. In 
one aspect a system for synchronizing data between a 

first system and a second system is provided. The sys- 
tem includes a first sync engine on the first system In- 
terfacing with data in the first system to provide differ- 
ence infomnation. A data store is coupled to networi<and 
in communication with the first and second systems. A 
second sync engine is provided on the second system 
coupled to receive the difference Information from the 
data store via the network, and Interfacing with data on 
the second system to update said data on the second 
system with said difference information. 

Difference Infomnatlon is transmitted to the data 
store by thef irst sync engine and received from the data 
store from the second sync engine. The system may in- 
clude a management server coupled to the network and 
In communication with the first sync engine, the second 
sync engine and the data store. The system may include 
a plurality of sync engines on a respective plurality of 
systems, each of said plurality of engines being coupled 
to receive difference information from each of said first, 
second and plurality of sync engines from the data store 
via the network. Each said engine interfaces with data 
on the system on which It resides to update said data 
on said system on which It resides with said difference 
information, and interfaces with data on said system on 
which It resides to provide difference data Information 
from the system on which It resides to the data store. 

In a further embodiment, the Invention comprises a 
method for synchronizing at least a first file and a second 
file resident on a first and a second systems, respective- 
ly, coupled to the Internet, respectively. The method In- 



cludes the steps of: determining difference data result- 
ing from changes to the first file on the first system; 
transmitting the difference data to a server via the inter- 

not: querying the server from a second system to deter- 
mine whether difference data exists for flies on the sec- 
ond system: retrieving the difference data to the second 
system; and updating the second file on the second sys- 
tem with the difference data. 
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Description 

BACKGROUND OF THE INVENTION 
s Field of the Invention 

[0001] The invention relates to the transference of data between two systems independent of the form in which the 
data Is kept on the respective systems, and in particularto providing an efficient means of communicating data between 
systems and devices. 

10 

Description of the Related Art 

[0002] The growth of computing-related devices has not been limited to personal computers or work stations. The 
number of personal computing devices has grown substantially in both type and format. Small, hand-held computers 

is carry a multitude of contact, personal, document, and other infonnation and are sophisticated enough to allow a user 
to fax, send e-mails, and communicate in other ways wirelessly. Even advanced cellular phones carry enough memory 
and processing power to store contact information, surf the web, and provide text messaging. Along with the growth 
in the sophistication of these devices, the need to transfer information between them has grown significantly as well. 
[0003] With a multitude of different device types on the market, keeping information between the different devices 

20 synchronized has become increasingly problematic. For example, if an individual keeps a calendar of information on 
a personal computer in his or her office using a particular personal Infonnation manager application, the Individual 
would generally like to have the same Infonnation available In a cellular phone, hand-held organizer, and perhaps a 
home personal computer. The individual may additionally have a notebook computer which requires synchronizing file 
data such as presentations or working documents between the notebook and the office computer, 

25 [0004] Until now, synchronization between both documents and personal information managers has occurred through 
direct connection between the devices, and generally directly between applications such as a personal information 
manager in one device and a personal information manager In another device or using an intermediary sync-mapping 
program. 

[0005] One example of this Is the prevalent use of the 3Com Palm® OS-based organizer, such as the 3Com Palm® 
30 series of computing devices, which uses its own calendaring system, yet lets users synchronize the data therein with 
a variety of different personal information manager software packages, such as Symantec's ACTF", Microsoft's Out- 
lookf®, and other systems. In this example, an intermediary synchronization program such as Puma Technology, Inc. 
's Intellisync® is required, Intellisync® is an application program which runs on both the hand-held device and the 
computer which stores the information data and maps data systems between non-unifonn data records. In other cases, 
35 direct transfer between applications such as transfer between Microsoft's Outlook® computer-based client and l\^lcro- 
soft's Windows CE "Pocket Outlook" application, is possible. Nevertheless, in both cases, synchronization occurs 
through direct connection between a personal computer and the personal computing device. While this connection Is 
generally via a cable directly connecting, for example. Palm® device in a cradle to the personal computer, the connec- 
tion may be wireless as well. 

40 [0006] One component of these synchronization systems is that the synchronization process must be able to delin- 
eate between when changes are made to specific databases and must make a decision about whether to replace the 
changed field. Normally, this Is measured by a change in one database, and no-change In a second database. In some 
cases, both databases will have changed between syncs. In this case, the sync operation must determine which of 
the two changes which has been made is to "win" and repiace the other during the sync. Generally, this determinant 

45 of whether a conflict exists allows some means for ietting the user resolve the conflict. 

[0007] In a technical sense, synchronization in this manner is generally accomplished by the copying of full records 
between systems. At some level, a user Is generally required to map data fields from one application to another and 
specify which data fields are assigned to which corresponding field In a different device. Less mapping is required 
where developers more robustly support various platforms of applications. 

50 [0008] In many instances, the data to be synchronized is generaliy in the form of text data such as records of ad- 
dresses, contact information, calendar information, notes and other types of contact information. In cert:ain Instances, 
data to be synchronized will be binary format of executable flies or word processor-specific documents. In many cases 
where document synchronization is required, the synchronization routine simply detennines whether or not the docu- 
ments in question have changed, and uses a time-based representation to detennlne which of the two files is newer, 

55 and replaces the older file with the newer file to achieve synchronization, as long as the older of the two files was in 
fact not changed. This Is the model used In the familiar "Briefcase" function in Microsoft Windows-based systems. If 
both files have changed, then the synchronization routine presents the option of conflict resolution to the user. Such 
synchronization schemes are generally relatively inefficient since they require full band-width of the document or binary 
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file to be transferred via the synchronization linl<. In addition, at some level the synchronization programs require in- 
teraction by the user to map certain fields between different programs. 

[0009] One of the difficulties in providing synchronization between different computing devices is that the applications 
and platfonns are somewhat diverse. 

5 [0010] Nevertheless, all synchronization programs generally require certain functions In order to be viable for wide- 
spread usage. In particular, synchronization programs must work with popular applications on various platforms. Sync 
applications must allow for conflicts resolution when changes are made to the same Information on different devices 
between syncing events. They must provide synchronization for ali types of formats of data, whether It be text data in 
theform of contacts, e-malis, calendar information, memos or other documents, or binary data In the fonn of documents 

10 or programs In particular types of formats 

[0011] In a broader sense, applications which efficiently synchronize data between disparate types of devices can 
provide advantages In applications beyond synchronizing Individual, personai Information between, for example, a 
personal Information manager hardware device such as a Palm® computing device, and a personal computer. The 
same objectives which are prevalent in developing data transfer between personal information management (PiM) 

is devices and desictop systems lend themselves to furthering applications requiring data transfer between other types 
of devices, on differing platforms. These objectives Include speed, low bandwidth, accuracy, and platform independ- 
ence. 

[0012] For example, current e-mail systems use a system which is somewhat akin to the synchronization methods 
used for disparate devices In that an entire message orfiie is transferred as a whole between different systems. When 
20 a user replies to an e-mail, generally the entire text of the original message Is returned to the sender, who now has 
two copies of the e-mail text he/she originally sent out. The same is true if an e-maii attachment is modified and returned. 
All of the text which Is the same between both systems is essentially duplicated on the originator's system. 

SUi\;ilVIARY OF THE INVENTION 

25 

[0013] The Invention comprises a system and method for efficiently, quickly and easily synchronizing devices which 
can couple to the Internet, or any networi<. Synchronization of the devices can occur at independent times using an 
intervening network based storage server to store changes to data for all the different devices in the system In a data 
independent fonnat, and provide the data on request to the device requesting a sync at the time requested. IHence, 

30 two devices need not be coupled to each other to perfonn a sync. 

[0014] In one aspect the invention comprises a system for synchronizing data between a first system and a second 
system. The system includes a first sync engine on the first system interfacing with data on the first system to provide 
difference Information. A data store Is coupled to networic and In communication with the first and second systems, A 
second sync engine Is provided on the second system coupled to receive the difference Information from the data store 

35 via the network, and interfacing with data on the second system to update said data on the second system with said 
difference Information. 

[0015] Difference Information Is transmitted to the data store by the first sync engine and received from the data 

store from the second sync engine. The difference information is transmitted to the data store at a first point in time, 

and received from the data store at a second, subsequent point in time. In a further aspect, the second sync engine 
40 can Interface with said data on the second system to provide second difference Information to the data store and the 

first sync engine may thereafter couple to the data store to retrieve the second difference Infonnatlon and Interface 

with the data on the first system to update said data on the first system with said second difference infonnation. 

[0016] The system may Include a management server coupled to the network and in communication with the first 

sync engine, the second sync engine and the data store. 
45 [0017] In a further aspect, the system may include a first device, coupled to the first system via the network, providing 

said data to the first system. In such Instance, the first system may be a sync server. 

[0018] The system may Include a plurality of sync engines on a respective plurality of systems, each of said plurality 
of engines being coupled to receive difference infomiatlon from each of said first, second and plurality of sync engines 
from the data store via the network. Each said engine Interfaces with data on the system on which it resides to update 

so said data on said system on which It resides with said difference information, and Interfaces with data on said system 
on which It resides to provide difference data information from the system on which It resides to the data store. 
[0019] In a further embodiment, the Invention comprises a system including a first device, a data store and a second 
device. Thefirst device Includes at least a first data file and first differencing code having an input and an output coupled 
to a network to receive first device data change transactions, based on said at least one data file, from and provide 

S5 change transactions to, said network. The data store Is coupled to the network and has at least one data structure 
coupled to store change transactions. The second device Includes at least a second data file and second differencing 
code having an Input and an output coupled to the network to receive said first device data change transactions, and 
provide second change transactions based on said at least second data file to said data store. 
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[0020] In a further embodiment, the invention comprises a method for synchronizing at least a first and a second 
resident on a first and a second systems, respectively, coupled to the Intemet, respectiveiy. The method includes the 
steps of; determining difference data resulting from changes to theflrstfiie on thefirst system; transmitting thedlfference 
data to a server via the Internet; querying the server from a second system to detennine whether difference data exists 
5 for flies on the second system; retrieving the difference data to the second system; and updating the second flie on 
the second system with the difference data. 

[0021] In a stiii further aspect, the Invention comprises an Internet synchronization system. The system includes a 
storage server having an Internet connection; a first device coupied to the internet and Including a device sync engine: 
and a second device coupled to the internet and including a second device sync engine. A management server may 
10 further be provided. In this aspect, each device sync engine may comprise an application object, an application object 

store, and a delta engine. 

BRIEF DESCRiPTiON OF THE DRAWiNGS 

15 [0022] The invention will be described with respect to the particular embodiments thereof. Other objects, features, 
and advantages of the Invention will become apparent with reference to the specification and drawings in which: 

Figures 1 - 7 are block diagrams of various configurations of the system of the present Invention utilizing the 
differencing routines of the present Invention, 
20 Figure 8 is an overview of one embodiment of the system architecture in accordance with the present invention. 

Figure 9A is a block diagram of the desktop device engine of the present Invention. 

Figure 9B is a block diagram of the configuration of server side device engines utilized In accordance with the 
present Invention. 

Figure 10 is a block diagram of one embodiment of the device engine in an operating system such as Windows. 
25 Figure 1 1 is a block diagram of an application object incorporated into the device engine of the present Invention, 

Figure 12 is a diagram of storage object hierarchy of a universal dataformat utilized with the system of the present 
Invention. 

Figure 1 3 Is a listing of exemplary item objects used in accordance with the routines of the present Invention. 
Figure 14 Is a block diagram of a management storage server architecture for used In the system of the present 
30 invention. 

Figure 15 Is aflow diagram illustrating a pull synchronization in accordance with the system ofthe present Invention, 
Figure 16 Is a flow diagram illustrating a push synchronization in accordance with the system of the present in- 
vention. 

Figure 17 Is a diagram of the management sen/er architecture in accordance with the present Invention. 

35 

DETAILED DESCRIPTION 

[0023] The present invention Includes a system and a method for transferring data between two devices which require 
Information to be shared between them. In accordance with the discussion herein, a "device" Is defined as a collection 

40 of elements or components organized for a common purpose, and may include hardware components of a computer 
system, personal information devices, hand-held computers, notebooks, or any combination of hardware which may 
include a processor and memory which is adapted to receive or provide information to another device; or any software 
containing such Information residing on a single collection of hardware or on different collections of hardware. Such 
software might Include applications such as personal information managers, which include contact data and other such 

45 Information, e-mail systems, and file systems, such as those utilized by Microsoft Windows NT operating systems. 
Unix operating systems, Linux operating systems, or other systems capable of storing file types having binary formats 
which translate to application formats of differing types, 

[0024] In one embodiment, the Invention comprises a set of programs specifically designed to transmit and/or receive 
differencing data from one device to another device, irrespective of the type of file system, data, content, or system 

so hardware configuration, 

[0025] in a further aspect, the system comprises store and forward technology which utilizes the differencing tech- 
nology to implement services via a public or private network, such as the Internet, 

[0026] The system of the present Invention finds particular usages In synchronizing personal contact information 
between different systems, but It will be readily apparent to one of average skill in the art that the present Invention 
55 provides advantages having broader applicability than merely synchronizing various types of systems. For example, 
replying and forwarding e-mall can be made more efficient by forwarding only the differences in e-mails between sys- 
tems. As a further example, updates to systems software via a network can be made more efficient where, for example, 
Instead of completely replacing different modules of an application, only the differences of the modules need be for- 
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warded, resulting in more efficient use of existing bandwidth. 
System Overview 

5 [0027] Figures 1 -7 show various configuration alternatives of the present invention. 

[0028] Figure 1 shows an ennbodlment of the present invention in a basic configuration. In Figure 1 , a first system 
or device, system A, and a second system or device, system B, are coupled by a communication line 110. It should 
be readily understood that communication line may be any direct coupling of the two systems which allows data to 
pass between the systems such as, for example, by means of serial ports, parallel ports, an Ethernet connection or 

10 other type of network, or an infrared linl<, or the lil<e. System A includes afunctional blocl< 1 00 representing a differencing 
transmitter in accordance with the present invention. System B includes afunctional blocl< 102 representing the differ- 
encing receiver in accordance with the present invention, 

[0029] The differencing transmitter 1 00, upon receipt of a control signal enabling operation of the transmitter, exam- 
ines a specified data structure of information which is to be transmitted to system B. Differencing transmitter 100 
is extracts such information from System A and converts the information extracted Into difference information A. Difference 
information A comprises only the changes to System B's data which have occurred on System B and instructions for 

implementing those changes. Hence, if the data to be transferred is a change to a file which exists on system B, 
difference information A comprises only the differences in such file and where such differences occur If the data does 
not exist at all on System B, the difference information A will be the entire file. Difference information A received by 
20 differencing receiver 1 02 at System B is reconstructed at System B, and the changes reflected therein are updated on 
System B. 

[0030] For example, If System A and System B are two computers and an update for certain binary files on System 
A is required, the differencing transmitter on System A will extract the differences In the file known to exist on System 

B and any new files, and transmit only those differences (an instructions for where to insert those differences) to the 
25 differencing receiver 102, Differencing receiver 102 will interpret the difference information (A) and reconstruct the 
binary files on System B. In this manner, the Information on System B is updated without the need to transfer the entire 
binary files between the Systems. 

[0031] Figure 2 shows a second example of the system of the present Invention. In Figure 2, both System A and 
System B include functional blocks 104, each representing adifferencing synchronizer. Thefunction of the synchronizer 
30 1 04 is similar to that of the transmitter and receiver combined; the synchronizer will allow difference information A to 

be both transmitted and received. For example. System A and System B are a portable computer and a desktop 
computer, respectively, where information such as contact information needs to be synchronized between the two, the 
differencing synchronizer 104 will extract changes made to the contact information on either System A or System B 
and at predetermined times, transmit the information A between the systems, and reconstruct the data on the receiving 

35 system to update information from the sending system, In order to ensure that both systems contain the same data. 
[0032] Figure 3 shows yet another alternative embodiment of the system of the present Invention. In Figure 3, System 
A again includes a differencing transmitter and System B includes a differencing receiver 102. In this embodiment, a 
storage server 300 is coupled between System A and System B. Storage server 300 may store a separate database 
of the difference information A provided by System A, which allows System A to provide its difference information A to 

40 the storage server 300 at a first point in time, and storage server 300 to provide the same difference information A to 
System B at a second point in time, but not the same as the first point in time. In addition, multiple sets of difference 
infomriation A may be provided at different points In time, and stored for later retrieval by System B. Still further, the 
difference information sets may be maintained on server 300 to allow data on either System A or System B to be 
returned to a previous state, 

45 [0033] Once again, the storage server 300 is coupled by a direct connection 11 0 to both System A and System B, 
Storage server 300 may be a server specifically adapted to receive differencing information A from the receiver 1 00 
and provide it to the transmitter 102. In one embodiment, server 300 includes specific functional routines for enabling 
this transfer. Alternatively, server 300 comprises standard information server types which respond to standard Intemet 
communication protocols such as file transfer protocol (FTP), or hypertext transfer protocol (HTTP). 

50 [0034] Figure 4 shows yet another alternative embodiment of the system of the present invention wherein System 
A and System B, once again coupled directiy to a storage server 300 by a direct connection line 110, each include a 
differencing synchronizer 104, Difference information A can be passed to and from System A through synchronizer 
1 04 to and from the storage server 300 at a first point in time, and to and from System B at a second point in time. In 
this embodiment, storage server 300 may Include routines, described below, for resolving conflicts between data which 

55 has changed on both System A and System B independently after the last point in times when the systems were 
synchronized. 

[0035] Figure 5 shows yet another alternative embodiment of the present invention including four systems: System 
A which includes a differencing synchronizer 104; System B which includes a differencing receiver 102; System C 
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which also includes a differencing synchronizer 1 04; and System D which includes a differencing transmitter 1 00. Each 
Is directly coupled to a storage server 300, allowing control of transmission of differencing data A between the various 
systems. Server 300 may Include routines, described in further detail below, to track the various types of systems which 
comprise System A through System D, and which control the transmission of various components of the difference 

5 information A to each of the various systems. For example, since System B includes only differencing receiver 102. 
the difference information Ag which is provided to it may be a sub-component of that which is transferred between 
System A in the storage server 300, or may be simply receiving broadcast information A4 from System D. in one 
embodiment of the system of the present Invention, server 300 does not Itself route the difference information derived 
from each receiver/transmitter/synchronizer. Server 300 acts as a repository for the Information, and the detennlnation 

10 of which difference information A Is attributed to which receiver/transmitter/ synchronizer is made by each receiver/ 
transmitter/synchronizer. 

[0036] Figure 6 shows yet another alternative embodiment of the present invention. In Figure 6. a synchronizer is 
provided in storage server 300. It should be recognized that a forwarder and/or receiver may be provided in server 300 
as well. The particular embodiment shown herein may be advantageous where device processing power and memory 

is are limited, such as cases where the device Is a ceil phone, it should be noted that the data transferred between system 
A and the device engine 1 04a In such an embodiment may or may not be difference Infonnation, depending on whether 
System A has the capacity to detect and output difference information. Each of the devices may Include a differencing 
receiver, a differencing transmitter, or a differencing synchronizer, it should be understood that a portion of the differ- 
encing synchronizer 104a may reside on System A and another portion may reside on server 300. 

20 [0037] Figure 7 shows yet another alternative embodiment of the present Invention wherein the devices shown in 
Figure 6 may be coupled to a combination of public or private networks 700 such as, for example, the Internet. The 
network 700 may Include one or more storage servers 300., ,3002, ^'^^ ''^ ^^'^'^ cases the difference information A 
transmitted between each such device 602-610 via Intermediate storage on one of such servers. Network 700 may 
couple the devices to one or more specialized function servers, such as servers specifically designed to include a 

25 differencing forwarder, receiver or synchronizer. Such devices may comprise, by way of example and without limitation, 
a personal office PC 602, a smart telephone 604, a user's office PC 606, a personal information Palm® computing 
device 608, a telephone or cellular phone 604, a home personal computer 606, or a web browser 61 0. Each differencing 
receiver, differencing transmitter, or differencing synchronizer present In devices 602-61 0 includes means to poll the 
data stored on storage servers 300., ,3002 '° determine whether the data present at storage server 300., ,3002 includes 

30 difference information which the particular receiver or synchronizer Is required to have to synchronize the data on the 
device on which it resides. 

[0038] In the following description, an embodiment wherein the differencing receiver, transmitter, and synchronizer 
are described will be discussed with respect to Its use in synchronizing contact information, calendar Information, and 
binary flie Information between a plurality of different devices in the context of data synchronization. It will be readily 

35 understood that the system of the present Invention Is not limited to synchronization applications, or applications de- 
pendent upon specific types of data, such as contact infonnation or scheduling information. In particular, it will be readily 
understood that the transmission of data comprising only the differences in data between two systems via routines 
which extract the data and reassemble data on the various systems, represents a significant advancement In the 
efficient transmission of data. The present Invention allows for optimization In terms of a reduction In the bandwidth 

40 utilized to transmit data between two systems, since only changes to data are transferred. This consequently increases 
the speed at which such transactions can take place since the data which needs to be transmitted Is substantially 
smaller than it would be were entire flies transfen'ed between the systems. 

[0039] In a particular embodiment of the present Invention , the ability of devices to connectto the Internet Is leveraged 
to manage data transfer between the systems. In essence, each particular device which requires information access 
45 which can connect to the Internet may become part of the system of the present Invention, and synchronize its data 
with other devices defined by a user as being part of the system. 

[0040] Generally, the system comprises client software which provides the functions of the differencing transmitter 
100, differencing receiver 102, and differencing synchronizer 104 In the form of a device engine. The device engine 
Includes at least one component particular to the type of device on which the device engine runs, which enables 

50 extraction of information from the device and conversion of the information to difference information, and transmission 
of the difference information to the storage server. This allows the replication of information across all systems coupled 
to the system of the present Invention. Although the storage servers 300 utilized In the system of the present Invention 
may be any type of storage server, such as an Internet server or an FTP server, and may be provided from any source, 
such as any Internet service provider (ISP), particular aspects of a storage server which may be useful and which may 

55 be customized to optimize transfer of information between systems coupled as part of the present invention will be 
described below. Synchronization of devices utilizing the synchronization system of the present Invention Is possible 
as long as an Internet connection between the devices is available. 

[0041] In a key aspect of the invention, the Internet connection between the devices or between the devices and a 
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server, need not exist at the same point in time, and new devices may be added to the system of the present invention 
at any point in time without the ioss of information. The system provides totaily transparent access to infomnation and 
the device engine on each device provides an operating system independent extension which aliows seamiess inte- 
gration of the personai information services in accordance with the present invention. 

5 [0042] In a particular unique aspect of the present invention, only those changes to the Information which are required 
to be forwarded to other systems on the system of the present invention are transmitted to enable exceptionaiiy fast 
response times, in a stiii further aspect of the Invention, information which is transferred in this manner is encrypted 
to ensure security over the public portions of the Internet. 

10 Architecture Overview 

[0043] Figures shows an overview of the architecture of the system of the present invention utilized for synchronizing 
or "syncing" Infornnation on different types of devices. In the embodiment hereinafter described, the system of the 
present Invention ailows the coupiing of a ooilectlon of personai devices and applications one uses when working with 

15 personal information. Nevertheless, the system may be used to broadcast public or private information to various device 
types. System software In the form of a device engine for each device which is declared a part of the system of the 
invention Is distributed across the collection of devices to enable synchronization. Distribution of the device engines 
may occur via, for example, an Instaiiation package forwarded over an Internet connection, in essence, the device 
engine software of the present Invention forms a distributed processing network which maintains consummate syn- 

20 chronization of all information in the system. The processing load associated with delivering this service Is pushed to 
the end-point devices which provides for easy scaling of the system to ever-larger applications. 
[0044] The present Invention contemplates the use of two types of device engine: one totaily embodied on the server 
which outputs change data to the server; and a second totaily embodied on the server receiving device generated 
change information from the device. In addition, a hybrid of the two, having a portion of the device engine on the device 

25 and a portion on the server, is disclosed, 

[0045] As shown In Figure 8, any number and type of devices 802-808 may be utilized in accordance with the system 
of the present invention. A telephone 802 may comprise a cellular phone or a standard POTS-connected telephone. 
Telephone 802 may include contact information and, as is supported with a newer generation of cellular telephones, 
appointments and task data stored In a data structure 812. The application 812 which utilizes the application data 822 

30 comprising such information is all stored in the telephone unit 802. Likewise, a personai digital assistant such as a 
Palm® computing device 804 includes application 814 and application data 824 which may Include Information such 
as contacts, appointments and tasks, and may also Include file Information such as documents which are created and 
stored on the PDA 804. Device 806 is represented as a Windows personal computer running an operating system 
such as IVIicrosoft Windows 95, 98, NT or 2000. Applications 816 which may be running on device 806 Include the 

35 Windows operating system Itself, iVIIcrosoft Outlook, Symantec's ACT Personai infonnation iVIanager, Goldmine Soft- 
ware's Goldmine, Lotus Organizer, Microsoft's Internet Explorer web browser, Netscape's Communicator Suite, Quai- 
comm's Eudora e-mail, and various other programs, each of which has Its own set of application data 826 which is 
required to be synchronized not only with devices outside the system 806, but also between devices and applications 
within the system itself. Finally, a dedicated web browser client BOB Is shown which couples via the Internet to web 

40 portal applications 81 6 which have their own set of application data 828. Unlike devices 806 which store the application 
and application data substantially In their own hardware, web portal applications are provided on a separate server 
and provided to browser 808 via an Internet connection. Nevertheless, the web portal application stored on the portal 
application provider includes a set of application data 828 which a user may wish to synchronize. For example, a large 
web portal such as Yahoo! and Snap, com provide services such as free e-maii and contact storage to their users. A 

45 user may wish to synchronize this with applications running on their cellular plione, PDA, or Windows devices. 

[0046] In order to access the specific application data of each of the systems shown in Figure 8, a device engine Is 
associated with each type of device, A cellular device engine 862 communicates and Incorporates itself with the ap- 
plication data 822 of the cellular phone. Likewise, a PDA device engine 864 Is provided, which may be based on either 
the Palm® operating system, Windows CE operating system, or other PDA-type operating systems as necessary. A 

50 Windows-based device engine 866 includes a mechanism, discussed below, for extracting application data 826 from 
supported Windows applications 816, and a web sen/ices device engine 868 incorporates to extract application data 
828 from web portal applications 81 8, 

[0047] As shown in Figure 8, some device engines are provided entirely on the device (and are referred to herein 
as desktop device engines), while others Include components a the back end server (which may comprise storage 
55 server 850 or a specialized server, as shown In Figure 9B.) This is illustrated generally by lines 832, 834,836, and 838 
in Figure 8. Also, In Figure 8, elements above dashed line 855 are provided by an administrator or service provider of 

the system of the present invention. Each of the device engines 862, 864, 866 and 868 is configured relative to the 
type of device on which it resides. For example, the Cell phone device engine 862 Includes one or more components 
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arranged on the phone while others are on server 850. Conversely, device engine 866 resides entirely on the windows 
device 806. 

[0048] Data from each of the devices Is coupled via an Internet connection 71 0 with a storage server 850. As noted 
above, storage server 850 may be a generic storage server or it may be a storage server specifically adapted for use 

5 with the system of the present invention as discussed below. One or more of the storage servers 850 are used to 
communicate transactions amongst the collection of systems 802, 804, 806, 808. It should be readily recognized that 
any number of different types of systems 802, 804, 806, 808 may be provided in accordance with the present Invention 
and Incorporated Into the system. However, for brevity, not all the different types of commercially available computing 
devices which are currently In use or in development. In which the system of the present Invention may be Incorporated, 

10 are listed. 

[0049] In Its simplest embodiment, the storage server 850 is simply a dumb storage server and each of the device 
engines transmits only difference information thereto to be stored in a particular location accessible by other device 
engines In the system. In one embodiment, each device engine Implements ail processing required to keep all the 
systems fully synchronized. Only one device engine needs to be coupled to the storage server 850 at one particular 
is point In time. This permits synchronization of multiple systems in a disconnected fashion. Each device engine will 
download all transactions encapsulating changes that have occurred since the last synchronization from the server 
and apply them to the particular device. 

[0050] The change or difference information (A) is provided In one or more data packages, the structure of which Is 
described herein. Each data package describes changes to any and ail transfer information across ail device engines, 

20 Including but not limited to application data, files, folders, application settings, and the like. Each device engine can 
control the download of data packages that Include classes of infonnation that apply to the specified local device 802, 
804, 806 or 808 attached to that specific device engine. For example, device engine 862 will only need to work with 
changes to information describing contact names and phone numbers in application data 822, while device engine 
866 will be required to work with changes to e-mail, changes to document files, notes, as well as contact and address 

25 information since the application data 826 Is much more extensive than application data 822. 

[0051] Each device engine Includes compression/decompression and encryption/decryption components which al- 
low encryption and/or compression of the data packages transmitted across Internet connection 71 0. It should be 
recognized that compression and encryption of the data packages may be optionally provided. It is not required In 
accordance with the present Invention. Each device engine performs mapping and translation steps necessary for 

30 applying the data packages to the local format requlredforthattype of Information In the application data stores 822-828, 
The device engine also Includes components which allow it to track ambiguous updates in cases where users have 
changed data to a particular data field on two different systems simultaneously since the last update. In this case, the 
device engine Includes a mechanism for drawing this to the attention of the user and allowing the user to resolve the 
conflict. 

35 

Device Engine Architecture 

[0052] Figure 9A Illustrates a single device engine utilized with a generic application 81 0 and a generic storage server 
850, Figure 9A Illustrates a desktop device engine, since all processing occurs on the device and only difference 
40 information is transmitted to server 850. Nevertheless, an understanding of the desktop device engine will aid in un- 
derstanding server side devices engines, hereinafter described. Shown In Figure 9 are the functional components of 
a device engine in block form and their Interrelationship to each other. The device engine 860 is equivalent to the 
functional block of a differencing sequencer 104 shown in Figures 1-7, 

[0053] While the Invention will be described with respect to the embodiment of the Invention as a differencing syn- 
45 chronizer 104, It will be readily understood that portions of the functionailty are utilized as needed in a forward-only (a 
differencing transmitter) or a receive-only (a differencing receiver) capacity as required by the particular application, 
[0054] As noted above, a device engine exists for each and every device that makes up a user's personal Information 
network of devices In the system. As shown In Figure 9A, each device engine 860 includes an application object 910. 
The application object Is specific to each particular application 810 and provides a standard interface between the 
so device engine and the balance of the data transmission system of the invention, and the application 81 0. Details of 
the application object will be described In further detail below. The application object is a pluggable architecture which 
supports a wide variety of vendor-unique applications. The job of the application object is to map data from the appli- 
cation into a temporary or "universal" data structure by connecting to the application via any number of standard inter- 
faces to gain access to the applications data. The data structure of the application object puts the data In a generic or 
55 "universal data" format which may be used by the device engine components to generate data packages for provision 
to the storage server. 

[0055] Also provided Is an application object store (AOS) 920 which includes a copy of the device's data at a point 
just after the previous data extraction and synchronization occurred. Application object store 920 is a mirrored Interface 
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which stores a snapshot of the previous state of the data from the appiicatlon object 910 In the device engine. The 
size of the AOS wiil depend on the data being coilected by each device engine. 

[0056] The generic output of the appiication object is provided to a deita moduie 950. Deita moduie 950 is a differ- 
encing engine which caicuiates differences in data between the output of the application object 91 0 and the copy of 

5 the data which is provided in an appiication object store (AOS) 920. The actual differencing and patch routine can 
comprise a routine such as XDelta or YDeita. The deita moduie 950 will be referred to herein alternatively in certain 
portions of the description as "CStructuredDeita." In addition, the difference Information is alternatively referred to 
herein as a "change log." Each change log (or set of difference infonnatlon) is a self describing series of sync trans- 
actions. As described below, the change log may be encrypted and compressed before output to the network. 

10 [0057] Hence, during a sync, the Application Object will, using a mechanism discussed below, extract the data of 
each application In the device and convert It to a universal data format. The delta module will then generate a difference 
set by comparing the output of the Application Object and the AOS. This difference Information Is forwarded to the 
encryption and compression routines for output to the storage server 850 in the form of a data package. Alternatively, 
the data from one appiication can be used to synchronize to data in another appiication In, for example, a windows 

is environment, as shown by an-ow 1050 in Figure 10. 

[0058] it should be specifically noted that the appiication object may Interface directly unstructured binary data or 
with structured application data. The differencing routine supports both uses of the deita module 950 in comparison 
generation. 

[0059] In some cases, operation of the application object and delta module is simplified by the fact that some appil- 
20 cations, such as PDA's, have the ability to output changes to Its data. In such cases, the delta moduie 950 need only 
provide the data Into the data package, since comparison to an AOS is not required - the application already includes 
a mechanism for traci<ing changes made to its own data. However, in many cases the applications provide, at most, 
a standard interface to access the data, such as i\^icrosoft's OBDC Interface, the iVIicrosoft standard Appiication Pro- 
gramming interface (API), or other similar standard interfaces. 
25 [0060] Device engine 860 further includes a versioning module which applies a version number per object in the 
data paci<age. As explained further below, each object in the data package Is assigned a universally unique ID (UUiD), 
Hence, unlike many prior synchronization systems, the system of the present Invention does not sync data solely by 
comparing time stamps of two sets of data. Versioning module 915 allows each device engine to check the state of 
the last synchronization against data paci<s which have been provided to the storage server to determine which data 
30 paci<ages to apply This allows the device engine to sync itself independently of the number of times another device 
engine uploads changes to the storage server. In other words, a first device engine does not care how many times a 
second device engine uploads data pacl<ages to the server. 

[0061] An events moduie 925 controls synchronization initialization events. Items such aswhen to sync, howtosync, 
trigger the deita moduie 950 to perfomn a synchronization operation. 
35 [0062] A user interface 930 Is provided to allow additional functional features to a system user of the particular device 
to which the device engine 860 is coupled. The user interface Is coupled to a conflict resolution module 940, a filtering 
module 945, and a field mapping moduie 935. Each of the modules provides the functionality both necessary for all 
synchronization programs, and which users have come to expect. 

[0063] Filtering module 945 allows filtering for types of content based on, for example, a field level content search. 

40 The field mapping moduie 935 allows forthe user to re-map certain interpretations of Items which were provided In the 
document stream. For example. If the device engine 860 is operating on a personal computer, and a synchronization 
Is occurring between the personal computer and a notebook computer, and the user has a "my documents" directory 
on the personal computer which he wishes to map to a different directory on the notebool< computer, the field mapping 
moduie 935 allows for this re-mappIng to occur. It should be recognized that the field mapping moduie allows for 

45 changes In directing the output of the data package. The field mapping module 935 is not necessary to map particular 
datafieids of, for example, contact information from one application, such as Microsoft Outlook, to a different application, 
such as Symantec's ACT, as is the traditional use of field mapping and synchronizing applications. 
[0064] Deita moduie 950 Is further coupled to a compression module 970 and an encryption module 960. It should 
be recognized that the compression encryption modules need not be enabled. Any type of compression module 970, 

so such as the popular PKZip orWinzip modules, or those available from HiFn Corporation maybe utilized in accordance 
with the invention. Moreover, any type of encryption algorithms, such as MD5, RCH 6, Two Fish, or Biowfish, or any 
other symmetric encryption algorithm, may be utilized. In one embodiment of the invention, encryption without com- 
pression is used. In a second embodiment of the Invention, compression without encryption is used. In a third embod- 
iment of the invention, neither compression or encryption Is used, and in a fourth embodiment of the invention, both 

55 compression and encryption are used. 

[0065] Versioning moduie 915 also allows the device engine 860 to support multiple users with distinct synchroni- 
zation profiles. This allows multiple users accessing the same machine to each synchronize their own data set using 
the same device engine. For example. If the application 81 0 on a particular device comprises Microsoft Outiool< on a 
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personal computer, coupled to a Microsoft Exchange server, and Outlook Is configured to have multiple user profiles, 
versloning module 91 5 will tracl< the data applied through the device engine when a sync request occurs. This allows 
two users of the same Outlook client software which access different data sets, either in the client computer or on a 
separate server, to utilize the same device engine and the system of the present Invention via the same machine, in 

5 a further embodiment, a particular device engine supports the use of foreign devices accessing the system via the 
same connection. Palm® devices, for example, use a cradle to connect to a computer and/or internet connection. If a 
particular user wishes to allow another user to use his Palm® pilot cradle connection to synchronize the other user's 
Palm® pilot, the device engine can generate data packages to update the local application object store for the foreign 
device. The application object store can therefore be used as a temporary storage for cases allowing synchronization 

10 of foreign devices. 

[0066] The output of the device engine 900 comprises a data package which is output to storage server 850. As 
noted above, only one device engine need be connected to the storage server 850 at a given time. The data package 
can be stored on the storage server 850 until a request is made to a particular location of the storage server by another 
device engine. Likewise, delta engine 900 can query alternative locations on the storage server for access to synchro- 
's nized data within the system of the present invention. Access to areas of the storage server is controlled by a man- 
agement server (MS) described more fully below. In one embodiment, each sync operation requires that the device 
engine for each device login to the management server to authenticate the device and provide the device engine with 
the location of the individual device's data packages on the storage server 

[0067] Data packages may be advantageously provided to the device engine from the storage server In a streaming 

20 format, allowing processing to occur using a minimum of bandwidth and storage In the devices. The device engine 860 
and particularly the delta module 950 interpret data packages based on the versloning Infonnation and the mirrored 
data present In the application object store 920. When data is returned to the delta module 950 from the storage server 
850, the delta module returns differenced data to the application object 91 0 for the particular application which then 
translates the delta Information into the particular Interface utilized for application 810. Once a device engine has been 

25 fully applied all data packages from an input stream, it generates a series of data packages that describe the changes 
made on the local system. The device engine uses the local application object store 920 to keep track of the last 
synchronized version of each application's actual data, which is then used for the next data comparison by the delta 
module on the next sync request. Generated data packages can include operations and encode changes generated 
from resolving ambiguous cases as described above. 

30 [0068] Figure 9B depicts how server based device engines may be provided In the system of the present Invention, 
The Palm® device example is shown in this embodiment, where the Palm® device has the capability of connecting 
directly to the internet and a service provider's data center 900, The data center Includes a firewall 975 to prevent 
unauthorized communications with servers resident in the data center 900 and protect integrity of the data, The storage 
server 850 may communicate directly through the firewall as may the management server (MS) 1410. 

35 [0069] Shown therein are two sync servers 982 and 984 each of which Is dedicated to syncing one particular type 
of application. Sync server 982 Is dedicated to the Palm® device, while sync server 980 Is dedicated to, for example, 
a portal application (Portail), 

[0070] Since the Palm® Device 804a Includes a mechanism for transmitting changes to its data directly data may 
be transmitted using HTTP request and response via the firewall 975 to the sync server 982 where differencing and 

40 updating of data in the AOS can occur after which changes can be downloaded to the Palm® 804a. 

[0071] The synchronization server is an application handles concurrent synchronization of user's data. Each Sync 
Server includes plug-In support for multiple devices to be synchronized using the same sync server executable. Each 
device type has it's own device name that Identifies which AO / AOS components will be used during the sync. 
[0072] The sync server uses the concept of a universal data record in Its Internal sync differencing engine and when 

45 sending data to and retrieving from externai entitles such as the AOS and AO, Hence, In the Palm® application, the 
job of a server AO Is simply to take the device-specific format of its record and convert Into a universal record format. 
[0073] The Sync Server has a plug-In architecture so that 3rd party application partners can easily add their services 
into the server Currently, If the server is operated In a Microsoft Windows NT Server, the sync server discovers the 
sync components via the Windows NT registry. In alternative embodiments, this function is perfonned In a Component 

50 Manger which operates on each sync server to manage processing by each of the AO and AOS on the server Each 
AO and AOS are implemented as a stand-alone DLL that the Sync Server loads at Initialization time, or when adding 
a new component via the Component Manager. 

[0074] Each sync server Is shown as dedicated to a single application. However, a sync server may handle multiple 
device types. 

55 [0075] in the embodiment of Figure 9B, it should be noted that, depending on the device type, there are different 
configurations forthe AOS and AO's. For example, the Paim®'s AO data store 1 050 resides on the Palm® device 804a 
itself and a separate AOS data store 1 052 exists for this configuration (an Oracle database), in the case of Portail , 
the AOS and AO use the data store 1 054. 
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[0076] Device engines can generate additional data pacicages intended to resolve synchronization problems in other 
systems. For example, interfacing with the conflict resolution module 940, If the user makes a change to a particular 
data store on an application object on his Palm® pilot, then makes an additional change to a personal infonnation 
manager (PIM) application on his personal computer, the user can specify that the change made on the personal 
5 computer will "win" when the conflict is detected by the A engine and the versioning information between the two 
devices.Thisisessentially a definition that one particular set of data is correct and should replace thesecond set of data. 
[0077] Figure 1 0 shows a specific embodiment of a desktop device engine utilized In, for example, a IVIIcrosoft Win- 
dows-based operating system environment. 

[0078] As shown In Figure 1 0, a Windows operating system may have at least three specific applications which may 

10 require synchronization. In Figure 10, the system includes Netscape Communicator application 1040 having data such 
as bookmarks 1021. contacts 1022, and e-mail 1023; a Microsoft Outlook application 1042 which includes contact 
information 1024, calendar information 1025, e-mail information 1026, note information 1027, and tasks information 
1028; and Windows operating system 1044 information including Favorites data 1029, file system information 1030, 
and individual files 1031. 

15 [0079] Each particular application 1040, 1042, 1044 has an associated application object 1010, 1012, 1014. Each 
of the respective application objects provides data back to delta module 950 In a generic fonnat which is usable by the 
delta module in accordance with the foregoing description of the apparatus shown in Figure 9A. From Figure 1 0, it will 
be additionally seen how the delta module 950 may be utilized to synchronize data between applications running on 
the same particular server The device engine hence does an intra-system sync such as, for example, between the 

20 contact Information 1 022 from Netscape and the contact Information 1 024 from Outlook. 

[0080] Figure 1 0 further Illustrates the modularity of the system of the present invention allowing the device engine 
to Include any number of different application objects to be provided on a single device to Incorporate all applications 
run on that device. 

[0081] In operation, during an installation of a device engine Into a particular system, the installation program may 
25 be tailored to provide application objects which may be present on a given system. For example, and with reference 
to Figure 10, the installation program for a Windows machine wili carry any number of application objects for systems 
and applications which may be present on a Windows machine. The installer will check for the presence of given 
applications, and allow the user to add additional applications which may be installed In locations that are not the 
nonnal default installation areas for application support by the application objects which the installer is carrying, or de- 
30 select certain applications which, for one reason or another, the user may not wish to Install an application object for 
and render a part of the system of the present Invention. 

Application Object Structure 

35 [0082] Figure 11 is a conceptual depiction of the structure of an application object. As noted above, the application 
object Is a pluggable architecture which supports a wide variety of vendor-unique applications. The consistent and 
scalable architecture of the system of the present Invention for device engines Is maintained by encapsulating system- 
dependent knowledge in a single component, i,e, the application object. As noted above, every application object 
supports a standard set of interfaces that every device engine understands. Each application object maps these stand- 

40 ard interfaces of the capabilities of a particular vendor application. Hence, there will be as many application objects as 
there are application types. 

[0083] As noted above, there are different types of server and desktop device engines, some having application 

objects entirely on the server, while others have application objects entirely on the desktop. 

[0084] Each application object will include a connector 1110 which may comprise a generic interface to the particular 

45 application forwhich the application object store has been designed. Forexample, when connecting to a Palm® device, 
the connector will be an HTTP protocol request routine which interfaces with the Palm® device's own built-in synchro- 
nization manager, which provides an output of records which have been changed on the Palm® device. As in Figure 
9B, since the Palm® outputs all the changes to Its data via Its own sync manager, in the Palm® application, the job of 
a server AO is simply to take the device-specific format of Its record and convert into a universal record fonnat. 

50 [0085] The connector provides access for the application object to remove the data field from a particular application 
and convert it to a universal record structure. In the desktop AO, where, for example the application object is designed 
for a Windows interface, the connector may be the Windows API and the job of the AO will be to translate data from, 
for example, the windows file system to a universal data format. This universal data structure is then used by the delta 
module 950 to build data packages to be used In synchronization between components of the systems provided in the 

55 network system of the present Invention, 

[0086] Universal data structure mapping, used on desktop application objects, and universal data record mapping, 
used by the server device engines, is further detailed below. 
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Desktop Application Object 

[0087] Each Application Object (AO) is a software component that Interfaces with the third party application APIs 
(Appiication Programming interface) to provide the programming services to the delta module for extraction and dep- 
5 osition of information data from and to the third party application domain during synchronization. In addition, the AO 

maps the third party application data fields to system's domain. 

[0088] The AO service is a collection of COM (Component Object Model) objects that can be developed in conjunction 
with the third party Windows application APIs as a fonn of a DLL (Dynamic Linl<ed Library) In C or C++. The DLL is 
loaded on demand at runtime during synchronization. It should be recognized that the appiication object need not be 
10 implemented using the COM model, but may be developed with other distributed object models. 

[0089] There are a number of the related subsystems and documents that the developer must be familiar with and 
this document has made many references to those subsystems during the course of presenting the AO. 

» Change Log (CL) (or differencing infomnation) , a data file which contains a series of synchronization transactions. 
15 » DataPack, a compacted and encrypted Change Log. 

• StructuredDelta, the delta module differentiation engine that generates differences between Application Objects 
and Change Log and AOS. 

• AOS, a database which resides locally on, for example, a windows machine. 

• MS, a management server that manages users' accounts. 
20 » SS, an FTP or storage sen/er that manages data packs. 

• User Manager, a standalone Windows client Ul program that manages the synchronization process. 

• ePortal, a web-based PIM portal site. 

• piojypes.h. a header file which contains the definitions of the system's supported data fields known as tags. 

• Del.h, a header file contains the definitions of the system's constants. 
25 t interfaces.h, a COM Interface file contains AO interface definitions. 

[0090] Each AO has a COM interface-based design bullt-ln. That is, instead of providing a set of traditional APIs as 
programming services, It provides a set of Interface-based objects as programming services. 
[0091] StructuredDelta, the delta module, the primary intended user of each AO. StructuredDelta Instantiates these 
30 COM objects and uses them throughout the synchronization session exclusivelythrough theCOM Interfaces on those 
objects to interface with the third party application database 

[0092] Each AO component consists of a set of objects that translate the third party application data into the universal 
data middle format which underpins the entire spectrum of PIM data regardless of which third-party application the 
data comes from. The objects in universal data format are device, (application) data class, store, folder. Item, and 

35 data fields. The AO digests the third party application data of any kind and reduces It Into a few handful simple objects 
and field types. These objects and field types are fed Into StructuredDelta engine and are compared by StmcturedDelta 
In order of their hierarchy. The resulting differences (add, delete, modify) are logged as transactions In the difference 
information , The data packs are transported to a storage server that may be actively managed by a management server 
for each individual user account and devices, 

40 [0093] StructuredDelta uses AO objects to access and modify the individual AO objects and data fields. AO objects 
serve as a buffer between individual application data and StructuredDelta so that StructuredDelta does not require 
knowledge of each application and database. All AO objects are temporary and created In the space of each AO by 
StructuredDelta through COM interfaces. AO objects are referenced when they are in use and they are freed when 
StructuredDelta stops using them. One can think of AO objects as merely placeholders of each application objects for 

45 StructuredDelta to access. Once StructuredDelta has a particular Application's data, StructuredDelta would free AO 
objects immediately without storing them internally. 

AppObj 

50 [0094] AppObj is a root object of each AO component and there is one and only one per AO, AppObj provides an 
entry point into the individual application's database. StructuredDelta instantiates it and holds it on during the entire 
synchronization session and releases it afterward, AppObj offers a number of services such as what class of data it 
supports. The C++ example of AppObj's definition Is shown below: 

55 
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class CMyFlAppObj : 

public Item, 
public AppObj, 
protected Moduleldentity, 
^ protected DataClassInfo, 

protected ItemTypeInf o, 
protected ItemFieldMap, 
protected Folderlnfo, 
protected DataFileInf o, 
protected SynchNotify, 
protected ErrorMsg, 
protected Enumltems, 
protected Findltem, 
protected Modifyltem 

15 ( 

public : 

CMyAppObi ( HWND hWndParent ) ; 
-CMyFppObj ( ) ; 

}; 

20 

[0095] AppObj can contain children objects. They are Store objects. Enumltems interface is used to enumerate 
Store objects. Findltem interface Is used to find the contained objects. Modifyltem interface enables AppObj to create 
a new Store object. AppObj is created by StructuredDeita calling CreateAppObject( HWND hWndParent, AppObj 
"ppObj). 

25 

Store 

[0096] The Store object represents a database of the individual application Infonnation. If the individual application 
can handle multiple databases at same time, one needs multiple Store objects. One can thini< of Store object as a 
30 specialized Folder object, the root folder of each particular application data domain. The C++ example of Store's def- 
inition is shown below: 

class CMyStore : 

public Item, 
public ItemContainer, 
protected Enumltems, 
protected Findltem, 
protected FindltemByData, 
protected Modifyltem, 
protected ReadWrite 

40 , 



45 CMyStore 0; 

-CMyStcre (I ; 



50 [0097] Store is a container of Folder objects. Enumltems interface enables tine enumeration of its contained folders 
whiie Findltem and FindltemByData interface is used to find contained Folders or Item objects. Modifyltem and 
ReadWrlte Interface enables the modification of each application database. 

Folder 

55 

[0098] Foider object is a specific data class of each individual application such as a table in the relational database 
or a coiiection of data records in each application. For example, the applications contact collection can be thought as 
a Foider object. The C++ example of Folder's definition is shown below: 
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class CMyFolder : 

public Item, 
public ItemContainer, 
protec::ed Enumltems,. 
protected Findltem, 
protectee FindltemByData, 
protected Modifyltem, 
protected ReadWrite 

( 

public: 

CKyFolderC ; 
-CMyFclcer () ; 

); 



15 [0099] Folder object is also container. It can contain Item objects as well as Folder objects. Enumltem interface 
allows the enumeration of either Folder objects or Item objects or both. FIndltem and FIndltemByData Interface is 
used to find contained Folder objects or Item objects. Modifyltem and ReadWrite interface enables the modification 
of an application's data tables. 

20 Item 

[0100] item object represents an Individual entity of each application's domain specific data, item object can be 
thought as a record of each application's relational table. For example, a contact, email, calendar, to-do Item In the 
particular application can be thought of as an Item object. The C++ example of item's definition Is shown below: 

25 

class CMylten : 

public Item, 
protected Enumltems, 
protected Findltem, 
protected Modifyltem, 
protected ReadWrite 

( 

publ i c : 

CMylteraO ; 
-CMyltemO ; 

35 J. 



[0101] Item can contain Attachment objects only. Enumltems interface enables the enumeration of Attachment ob- 
40 jects If any. Modifyltem and ReadWrite interface enables the modification of an application's records or data fields. 

Attachment 

[0102] Attachment object Is a specialized item object that encapsulates an attachment data or relationship. Only 
45 Item can have Attachment objects. Attachment object can be thought as attachment data such as attached-email flies. 
Attachment can also be thought as attachment relationship to other item objects. The example of that is the distribution 
list (Item object) can contain contacts (item objects). The C++ example of Item's definition is shown below: 



class CMylteiTiAttachraent : 
public Item, 
protected ReadWrite, 
protected Modifyltem 

public : 

CMylteia^ittachnent { ) ; 
~CMyIteniAttachirier.t ( ) ; 
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Variant 



[0103] Variant object represents a data field of each particular application data. For exampie, a 'first name' of a 
contact or the birthday date of a contact can be thought as Variant object. StructuredDeita only understands Variant 
s object and the types of data fieids it encapsulated. Variant object can contain any one of the foliowing data fieid type: 



struct Variant 



10 



enuitiFieldTag tag; 
snumFisldDataFlag flag; 
kncwn or otherwise special 
union 



f/ flags iten fields as not 



15 



20 



25 



eFleldType_Collection 
) Value; 
Stream* 





short int 


i; 


// 


eFieldType WORD 




LONG 


1; 


i I 


eFieldType_LONG 




DWORD 


dw; 


if 


eFieldType DWORD 




unsigned int64 


qw; 




eFieldType QWORD 




UUID 


uuid; 


/ / 


eFieldType UUID 




DATE 


tim.e; 




eFieldTyoe DATE 




LPTSTR 




ps z ; 


// 


eFieldType 


_String 










Binary 


bin; 




eFieldType_Binar 




Float' 


fit; 




eFieldTyoe Float 




Double 




dbl; 


// 


eFielcType 


Double 










FlColiection 


coll ; 


// 





stm; // eFieldType_Stream 



[01 04] Variant::tag is an identification tag of data field and variant: :f lag specifies the type of data fieid wh lie Variant:: 
30 value member variabie stores each appiication's fieid value. One data fieid type is Collection. Collection object is an 
array of Variant objects. It can be used to represent a compound data fields. 



struct Collection 
{ 

UlONG cValues; 

5truct_Variant** paVar; // This array really 

contains cvalues entrie.s 
}; 



40 



[0105] Another data fieid type that is worth expioring is Binary. Binary object can be used to represent a binary data 
as it is. 



45 



struct Binary 
{ 



50 



JLOSG cb; 
LPBYTE Ipb; 

}; 

55 
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AO Interlaces 

[0106] Each AO object has an AO COM interface. Each object must implement some of those Interfaces to create 
certain capability or desired behavior that are expected by StructuredDeita. 

s 

litem 

[0107] This Is the base Interface of ali application objects. It provides the Identification service to StructuredDeita. 
Every object must have a unique ID, parent unique ID, display name, and Item type Information (eltemType FOLDER, 

10 eltemType_CONTACT, etc). The unique ID is a unique string only in a given device, it is not persistent cross the internet 
to other devices. The ID usually comes from the third party application database domain such a unique ID of a record. 



interface litem : lUnknow- 
15 < 

" STDMETHOD_(LPCTSTR, GetUniquelD) () const PURE; 

STDMETHOD_(LPCTSTR, GetParentUniquelD) 0 const PURE; 

STDMErHOD_(LPCTSTR, GetDisplayName) () const PURE; 

STDMETHOC_(enumItemType, GetltemType) () const PURE; 

SrDMETHOC_ (BOOL, IsContainer) 0 const PURE; 

STDMETHOD (DATE, GetLastModif icationTime ) () cor.st PURE; 
20 STDMETH0d2(QW0RD, GetSize) () const PURE; 

STDMETHOD (DWORD, GetFlacs) ■ ) const PURE; 

) ; 



25 lltemContalner 

[0108] This Is the base Interface of ali application container objects (store, folder). These container objects must 
have this Interface implemented so that StructuredDeita would recursively descend in them if they have lltemContalner 
capability. 



interface IltemContainer : litem 
( 

STDMETHOD_(BOOL, ContainsItemTypel ( enunltemType elte.tiType ) PURE; 
STDMETr;OL)_(BOOL, ContainsDataClass ) ( enuir.DataClass eDataClass ) 

PURE; 



40 STDMETHOD_ (enumSpecialFolderType, GetSpecialFolderType) () PURE; 

STDMETHOD_(GU:d, GetMappingGUIO) () PURE; 



45 



lErrorMsg 



[0109] This Is an error-reporting interface for every application object, it is used by StructuredDeita to query the error 
string after a failure. The AO should Implement this on every object after the error occurs and before returning the 
so control to StructuredDeita. 

interface lErrorKsg : lUnknown 
( 

STDMETHOD(GetErrorString) ( LPTSTR pszError, int iBufLen ) 
55 const PURE; 

); 
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lEnumltems 

[01 1 0] This is an interface for coliection enumeration, used by StructuredDelta to enumerate tfie objects of the third 
party application database. lEItemEnumFlags {eltemEnumFlags_FOLDER, eltemEnumFlagsJTEM, and 
s eltemEnumFlags_ATTACHMENT) is used to enumerate oniy the requested type of objects. 



interface lEnuinl terns : lUnknown 
( 

STDMETHOD (ItemQueryStart) ( enumlterr.Type type, long 
SlCount, eltemEnuniFlags dwFlags ) PURE; 

STDMETHOD (ItemQueryNext) ( Item **ppltem ) PURE; 
STDMETHODdte^nQueryFir.ish) () PURE; 

) ; 



15 

IFindltem 

[0111] This is an interface for recursiveiy finding object within the third party application database, used by Struc- 
turedDelta to find application object by its unique ID. 

20 

interface IFindltem : lUnknovm 

( 

STDMETHOD(FinclStoreBylD) ( LPCTSTR pszUniquelD, ItemContamer 
**pprolder 1 PURS; 

25 STDMETHOj (FmdFclderBylD; ( LPCTSTR pszUniquelD, ItemCcntainer 

*'ppFolder ) PURE; 
STDMETHOD (FindltemBylD) ( LPCTSTR pszUniquelD, Item **ppltem ) 
PURE; 



30 



35 

iFlnditemByPata 

[0112] This is an interface for recursively finding the object that matches the search criteria data. The search criteria 
are represented as Collection that allows the multiple search field keys to be used during the search. The multiple 
40 objects may be found that match the search criteria. The interface also provides enumeration capability of the search 
results. 

interfa"e IFindltemEyData : lUnknown 

STDMETHOD(FincByDataStart) i enunltemType type, Variant* 
pSsarchKey, int* pnFound ) PURE; 

STDtlETHOD(FindByDataNext) ( LPTSTR pszEntrylD, int 
cbBufSize ) PURE; 

STDMETHOD(FindByDataFinish) (} PURE; 

I; 

50 

ll^odifyltem 

[0113] This is an InterfaceforStructuredDeitato add, delete, and re-parent application data in thethird party database 
55 during synchronization. 
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interface IModifylteni : lUnknown 
{ 

STDMETKOD (Add) I BOOL bFolder, enumlteir.Type type, Item 
'^ppltem ) PURE; 

STDMETHOD (Delete) () PURE; 

STDMETKOD (Move) ( ItemContainer * pDestFolder ) PURE; 

); 



10 



15 



20 



I Read Write 

[0114] This is an interface for accessing, writing, and mapping the tinird party appiication data fieids by Structured- 
Deita. it provides tlie capabiiity of read and write data fieids from and to the third party appiication database and tiie 
capabiiity of mapping data field of tine third party application to universal data format of the system of the present 
Invention. Any object that has data fieids and require field level synchronization must implement this Interface. 



interface IReadWrite : lUnknown 
( 



3TDlXETHCD(Rcad) (i PURE; 
3TDKETHCD (Commit) () PURE; 

STDKETHOD(GetfieldDa-ca) ( enumFieldTdc fieldTag, Variant 
"♦ppVariant ) PURS; 

25 3TDKETH0D(ReleaserieldData) ( Variant *pVariant ) PURE; 

3TDKETH0D(3etFieldData) ( const Variant *pVariant ) PURE; 

I; 



30 



lAppObJ 



[0115] This is an AppObj oniy interi'ace, it provides the capability of iogon and logoff to the third party applications 
during synchronization. The data class filter mechanism is used by StructuredDelta to fllterthe enumeration of contained 
35 data classes (eDataCiass_CONTACT, eDataCiass_CALENDAR, etc). 



interface lAppObj ; lUnknown 
{ 

STDMETHOD (Logon) ( HWND hWndParenL ) PURE; 
STDMETHOD (Logoff) 0 PURE; 

STDMETHOD (SetFilter) ( const VOID* pFilter, int BufLen ) 

PURE; 

STDHETHOD_(int, GetFilter) ( VOID* pFilter, int BufLen ) 

PURE; 



IModuleldentity 

50 [0116] This is an AppObj oniy interface. It provides DLL module Identification information to the iVIanager object such 
as the name of the third party application, enum ID of this appiication, and the application installation detection support. 



55 
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10 



15 



20 



25 



30 



35 



45 



interface IMcduleldentity : lUnknown 

STDMETHOC (GetName) ( LPTSTR pszKarae, int iBufLen ) const 

PURE; 

3TDMETH0D IGetAppl) ( Appl *pAppl j const PURE; 
STDMETHOCdsInstalled) ( BOOL *blsl::stalled ) const PURE; 



lltemTypelnfo 

[0117] This is an AppObj oniy interface. It provides the information on the number of item types supported by AO, 
what type Items are supported and the capabilities for a specific item type. This returns a DWORD containing bits set. 



interface Ilteir.Typelnfo : lUnkr.owr. 
( 

STDMETHOD (G9tSupportedType.sCount:i ( int siCount ) PURE; 

STDMETHOD (GstSupportedTypelnfo) ( int ilndex, enumltemType 
Styps, IPTSTR pszTypeNaine, int iBufLen ) PURE; 

STDMETHOD (GetltemTypeCaps) { enum: LemType type, DWORD 
4dwFlags ) PURE; 
}: 



iDataCiassinfo 

[0118] This is a CAppOb] oniy interface. It provides the infonnation on the number of data classes that are supported 
by the application object and what the data classes are supported 



interface IDataClassInfD : lUnknown 
i 

STDMETHOD (GetCount) ( mt *piCount ) PURE; 

STDMETHOD (GetDataClass; ( int ilr.dex, enumDataClass 
♦peDarsClass ) PURE; 
); 



40 IDataFlieinfo 

[0119] This is aCAppObj only Interface, It provides Information on the number of database files and database filena- 
mes supported by AO to avoid being synched twice by application sync and file-set sync. 

interface I DataFilelnfo : lUnkncwn 

{ 

STDMETHOD (GetDataFileCount) ( int *piCount ) PURE; 
STDMETHOD (GetData?ilePath) ( int .ilndsx, LPTSTR 
pszFilePath, ir.t iBufLen ) PURE; 

50 



litemFieidMap 

S5 [0120] This Is a CAppObj only Interface that is used by StructuredDelta to query the data fields of given application 
object. For example, what are data fields In application object called eltemType_CONTACT? 
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interface IltemFieldMap ; lUnknown 

{ 

STDMETHOD ( FieldQueryStart ) ( ccnst enuml-emType Stype, int 
siCount ) PURE; 



STDMETHOD (FieldQueryNext I ( enumFieldTaq sfield, LPTSTR 
pszName, int iBufLen, LPTSTR pszType, int ITypeBuflen )PURE; 
STDMETHOD (FieldQuervFinish) () PURE; 

I; 



15 

IFolderlnfo 

[0121] This is a CAppObj only interface, used by StructuredDelta to obtain the special and default folders' unique 
IDs and UUIDs. 

20 

interface IFolderlnfo : lOnkncwn 
{ 

STDMETHOD (GctSpecialFolderlD) ( enuraSpecialFolcerType 
eFclder, LPTSTR pszUniquelD, int iBuflen ) PURE; 
25 STDMETHOD (GetDefaultFolderlD) ( enumltemTypG type, LPTSTR 

pszUniquelD, int i3jfLen : PURE; 

STDMETHOD (MapfolderGUID) ( UUID uuidFolder, LPTSTR 
pszUniquelD, int iBufLen ) PURE; 

I; 

30 



IFastSync 

[0122] This Is a CAppObj only Interface that Is used by StructuredDelta to query If the given AO also provides Fast- 
35 Sync sen/Ice or not. FastSync Is a DLL component that is written using the third party APIs and loaded Into the third 
party application to receive the changes in database while users are operating the application. It Is used to speed up 
the synchronization performance by syncing only the objects that are known to IFastSync component. 



40 interface IFastSync : lUnknown 

( 

STDMETHOD (GetFastSync) ( enuiriDataClass eDataClass, EOOL* 
pbFastSync ) PURE; 
}; 

45 



SynchNotify 

[0123] This is a CAppObj only interface that is called by Manager to notify the third party application the state of 
so synchronization: start, finished, or reset so that the application can prepare itself accordingly. 

interface ISynchMotify : lUnknown 
( 

55 
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STDMETHOD(SynchNotify} ( enumSynchNctif y eNotify ) PURE; 



Server AO 

[0124] Server Application Objects share many characteristics with desi<top appiication objects, inciuding support for 

10 reading and mapping to the universal record structure set forth above. 

[0125] Nevertheless, among various devices incorporated into the system of the present invention, each application 
object database will be quite different. For example^ the Palm® database on the device is really just a memory space 
with records laid out sequentially in memory. In a web portal-type application, the appiication object may be an Oracle 
database. Server application objects may generally have less difficult tasks since the applications supported are gen- 
's erally either devices providing their own change data output, (such as Palm®-type PDA's), or which do not have a 
great deal of data to export (such as cell phones, having only name and number information). 
[0126] Nevertheless, each application object must support all calls defined in a class interface definition as follows: 



FUNCTION 


DESCRIPTiON 


Open 


Perform an initialization of the device before data retrieval functions are called. 


Close 


Done with database calls, cleanup if necessary. 


Get First Modified Record 


Get the first modified record from the device and insert into appiication object. 


Get Next l\/lodified Record 


Get the next modified record from the device and insert into the application object. 


Add Record 


Add a record into the application object database. 


Update Record 


Update a record. 


Delete Record 


Delete a record in the application object database. 


Set Device Records 


A function called during the synchronization manager to send a bytestream to the 
application object for interpretation. The bytestream will contain a list of records to add 

to the application object modified records list. At a later point in time, such records will 
be retrieved by the Get First IVIodified Record/Get Next H/lodified Record functions. 


Get Device Records 


For records bound to the device, this call gets a bytestream that contains a list of 

records to add back to the device. There is an outbound record list that is saved until 
this call is finished, at which time the sync server will be finished with the application 
object 


Set Device Response 


A function used to modify or repair a record input saved in the application object store 
that was sent to the device in the Get Device Records call, such as a record ID for a 
record. If 10 records were sent to the device during the Get Device Records call, one 
would expect to see 1 0 records coming back In during this function call. 



45 [0127] As noted above, because each application object database is different, the calling convention and the appli- 
cation object itself will likewise be different. The calling convention for a Palm® device's sync manager application 
object is given in the following pseudo-code: 
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Call AO: :Oper. 

Call AO: :WriteRecords 

Start Eynchronization process 

While ncre records in AC Data Object 

Call AO: : GetFirstModif iedRecord ( ) 
Call AO: :GetNextModif iedRecord ( ) 

END 

IF new records THEN 

Call AO: :AddRecordO 
IF deleted records THEN 

Call AO: : DeleteRecord ( ) 
IF update record THEN 

CALL AO: ;UpdateSecord() 



Call AO: : Close 



As shown therein, the calling convention Is designed to be Integrated with the Palm's® own sync manager 
[0128] A second example provided below shows mapping of a portion of a web portal's contact database: 
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Mappingltem CContactTable : :n FieldMapd = 
I 



5 



10 



15 



( 1, 


eFieldTag Contact 


r irstName, 


"f irstnarr.e" ) , 


u, 


eFielcTag Contact 


MiddleName, 


"ir.iddlenaTne" ) , 


(1, 


ePielcTag Contact 


LastName, 


"lastname" } , 


( 1, 


eFieldTag Contact 


?itle, 


"title") , 


( 1, 


eFieldTag Contact 


Suffix, 


"suffix" ) , 


(1, 


eFieldTag Contact 


Anniversary, 


"anniversary" ( , 


11, 


eFieldTag Contact 


Birthday, 


"bi rthcay" } , 


( 1 , 


eFieldTag Contact 


AssistsntName, 


"flssistantname" ) , 


u, 


eFieldTag Contact' 


'children, 


"children" ) , 


il, 


eFieldTag Contact 


CompanyKame, 


"companyname" } , 


u, 


eFieldTag_Cont3ct^ 


Department, 


"department " } , 


a, 


eFieldTag_Conract_ 


_FTPSite, 


"ftpsite" } 


u. 


eFieldTag Contact 


Gender, 


"gender" ) , 


(1, 


eFieldTag Contact 


"jobTitle, 


"jobtitle"}. 


(1, 


sFieldTag Contact 


ManagerName, 


"managername" } , 


(1, 


eFieldTag_Contact_ 


NickKame, 


"nickname" } , 


(1, 


eFieldTag Contact 


"office, 


"office" ) , 


il, 


eFieldTag Contact" 


Profession, 


"profession" ) , 


(1, 


eFieldTag^Contact" 


Spouse, 


"spouse" ) , 


(1, 


eFieldTag Contact 


Select edMailingAddress, 




"seiectedirLaiiingaddress" ) 





1 ; 

int CContactTable : :m_nNum.- ields = 
sizeof !ir._FieldMap) /sizeof (Mappingltem) ; 

HRESULT CPortdlfiddrOCI : : InsertEecord ( Mappingltem theMapi;, int 
25 numFields, CDataAccessor *plnsertltem, CFlIteir.Universal *pUnivItem, 

bool bForceCreate ) 
{ 

bool bHasData = SetRecordFields ( theKap, numFields, pinsertltem, 
pUnivItem ) ; 

30 if( bHasData II bForceCreate ) 

{ 

// Insert the recorc into the database and execute the command 
pInsertIte:n->InsertRow (O; ; 
DlnsertIte:n->Exec ( ) ; 

) 

35 

return S_OK; 

) 

[0129] The above example of mapping the contact field files maps contact fields from a particular web contact infor- 
40 mation database to fields in the universal record format from the master list header file (pio_types,h) in the system of 
the present Invention. This mapping is for a specific contact table and it should be understood that other information, 
such as phone numbers, e-mail addresses, and other contact information may be stored in a separate table. 
[0130] Once data is extracted from a particular application, the server application object must then convert the in- 
formation into the universal record format which can be utilized by other server device engines to take content infor- 
ms mation into their own particular application. 

Universal Record Format 

[0131] The universal record foniiat is used by each server device engine to handle various tasi<s of encapsulating 
so records in a common fomnat, comparing records, creating and holding differences between records, and other tasks 

of synchronization. 

[0132] The universal record format allows the application objects to support a wide range of extensible application 
item types such as contacts, calendar, mail, bookmarks, and the like. Flexible type name and value associations permit 
synchronization without regard to individual vendor application information formats. Each application object encapsu- 
55 lates mapped knowledge from the vendor unique format to the universal fonnat of the present invention. As such, an 
application object can be designed to support any combination of application and binary information types. In essence, 
application objects can be designed to support a vendor application using only binary file synchronization if the internal 
format of the application is not known. 
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[0133] Server application objects can also be designed to create collections. For example, if the user wishes to create 
a "my pictures" collection which consists of some collection of Infonnation and synchronize this collection of Infonnation, 
such an arbitrary grouping of classes of information into appropriate representations is supported. 
[0134] Because the connector layer of the Interfaces to the actual storage with a vendor application varies with 
application type, application access methods can Include, but are not limited to, disk or database access, networl< 
protocols, wireless device protocols, and the like. 

[0135] The Universal Records Forniat and the Universal Field Fonnat class definitions are given below: 



typedef map < enumFieldTag, CUnivers=lField, less_enuraFieldTag > 

CniversalRccordMap; 

typcdcf UniversalRecordHap; :value_type UniversalRecordPair ; 
typedef UniversalRecordMap; ;iterator L'niversalRecordlterator; 
typedei UniversalRecordMap: : const_iterator 
ConstUniversalRecordlterator; 



class CUniversalRecord 

f 

private: 

UniversalRecordMap recordMap _; 

public : 

bcol conflicts (const CUniversalRecorcS rhs); 
bool add(cor:st CUniversalRecord Srhs); 
bool subtract (const CUniversalRecords rhs); 



CUniversalRecord i j ; 

CUniversalRecord ( const CUniver-salRecords rhs ); 
virtual -CUniversalRecord ( ) ; 

// add this elenent 

KRESULT insert ( enumFieldTag eld, long value, 
snumFieldDataFlag iiag = eFieldDataFlag_Normal) ; 

HRESULT insert ( enumFieldTag eld, LPCTSTR value, 
er.uiiiFieldDataFlag flag = eFiGldDataFl3g_Normal ) ; 

HRE.SULT insert ( enumFieldTag sld, DATE value, 
enumFieldDataFlag flag = eFielcData?lag_Normal ) ; 

KRESULT insert ( enumFieldTag eld, string value, 
enumFieldDataFlag flag = eFielQDatarlag_Normal) ; 

HRESULT insert ( UniversalRecordPair p ); 

CUniversalRecord exclusiveLef twins ( CUniversalRecord^ rhs ) ; 
CUniversalRecord inclus ivsLef twins ( CUniversalRecordi rhs 1 ; 
bool removeSame (ccnsL CUniversalPvecord Srhs); 

bool Findi const enumFieldTag eld, CUniversalField sfield ); 
UniversalRecordMap :: iterator find( const enumFieldTag eld ) { 
return recordMap_. find (eld; ; } 



UniversalRecordMap: : iterator begin ( ) { return 

recordMap_. begin 0 ; } 

Ur.ivgrsalRecordMap: : iterator endO ( return 

recorcKap_. end ( ) ; ) 

bocl empty (} : return 

recorcKap_. empty 0 ; ! 

long sized { return 

recordMap_. size { ; ; ) 

UniversalRecordMap: : iterator erase (UniversalRecordMap ; : iterators 

it) 

( return recordMap_. erase (it) ; } 
void clear 0 { recordMap_. clear () ; ) 

}; 
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The UniversalField Structure 



[0136] 

s 

class CUniversalField 
( 

public : 

enum eUr.iversalField 
f 

10 eUF_Unknown, 

eUF_Long, 
eUF_String, 
eUF_Date, 
eUF_Blob 

I; 

15 

projected: 

eUniversalField typeld_; 
enumFieldTag fieldid ; 

enumFieldDataFlag flag_; 
size_t len_; 

20 

union 
( 

long 1; 
DATE d; 

TCHAR* pCh; 
25 1 value_; 

public : 

CUniversalField (} ; 

CCniversa IField ( ccnst CUniversalField* rhs j ; 

CUniversalField i enumFieldTag itemid, long value, 
enumFieldDataFlag flag = e?ieldDataFlag_Ncrraal) ; 
^° CUniversalField ( enumFieldTag iteirJd, DATE value, 

enumFieldDataFlag flag = eFieldDatariag_Kornal) ; 

CUniversalField! enumFieldTag itemid, LPCi'STR value, 

enumFieldDataFlag flag = eFieldDataFlag_Normal) ; 

CUniversalField I enumFieldTag itemid, string blob, 
enumFieldDataFlag flag = eFieldDataFlag_Ncrmal ) ; 
35 ~CUniversalField ( ) ; 



bool operator==( const CUniversalFields rhs ) const; 
bool operator ! = ( const CUniversalt'ields rhs ) const ( return 
! operatcr== ( rhs ; ; 1 

COnlversalFields op=rator=( ccnst CUniversalFiel d4 rhs); 

eUniversalField ge^TypeO const i return typeld ; 1 
enumFie.dTag getFieldlDO const I return fieldld_; } 
enumFieldDataFlag getFlagO const ( return flag_; ) 

size_t getLengthO const (return len_; ) 



45 


LPCTSTR getString!) const 


{ ASSERT ( 


eUF 


String 




typeld ) ; return value .pCh ; ) 










long getLongi) const 


{ ASSERT ( 


eUF_ 


Long == 




ti'peld_) ; return value .1; ) 










DATE getDatef) const 


( ASSERT ( 


eUF 


Date == 




typeld ) ; return value .d; ) 








50 


string get31ob() const 


{ ASSERT ( 


eUF_ 


Blob — 


typeld ); return string (value 


. pCh, len ) ; ) 








void get ( LPCTSTRs p ) const 


{ ASSEKT( 


eUF_ 


String == 




typeld ) ; p = value .pCr.; ) 










void get ( longs 1) const 


\ ASSERT ( 


eUF_ 


_Long == 


55 


typeld ); i = value .1; ) 










void get ( DATES d) const 


( ASSERT ( 


eUF 


_Date == 
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typeld_) ,- c = value_.d; 1 

void get ( strings b) const { ASSERT ( eUF_Blob ===^ 

typeld_) ; b. assign (val'je_.pCh, len ) ; ) 



bool isStringO const 
eUF String; ) 



bool isLong 
bool isDate 



const 
const 



bool isBlobi) const 



■ return typeld_ == 

I ret. in ^yp&Id == eUF_Long; } 

I return Lyp6ld_ == eOF_Date; } 

1 return typeld_ == eUF Blob; } 



Example 

[0137] An example of how data is removed from one particular application data type and converted into the universal 
record fonnat Is given below for an Oracle database: 



include "s^dafx.h" 

# include <str_ng> 
using namespacs std; 
#include "FlltemUniversal.h" 

ftinrludc "cci.h" 
^include "OCIDefs.h" 
#include "OCIConnect 
^include "OCISessicn.h" 
♦include "OCIColumn . h" 
♦include "OCICursor.h" 
♦include "DataAccessor .h" 

* include "Univer salMapper . h" 
S include "UniversalRecord.h" 
(t-nclude "FlUtil.li" 

#include "BaseAOSTableCCI .h" 



/* 

* Function: KapFields 

* Description: Map fields from an Oracle database record into an 
UniversalRecord format. 

*/ 

void CBaseAOSTableOCI : :MapFields ( CDataAccessor *pAccessor, Mappingltem 

theMap[li int numb'ields, CUniversalRecord SunivRec ) 

{ 

string sValue; 
DATE dtValue; 
LONG lvalue; 
double cValue; 

f or ( int inx=0; inx<numFields; inx++ ) 
{ 

enumFieldTag fieldID = theMap [inx] .m_universalFieldID; 

switch! FlPropTvpel fieldID ) ) 

{ 
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case eFieldType_Binarv: 
( 

// to fill properly, 1st name and last name should already be assigned 
* CUniversalField emailField; 

string sValue; 

if { SUCCEEDED !BuildEmailField( pAccessor, 

sValue, emailField ) ) ) 

univRec . insert ( fieldID, 

10 emailField. getBlobO ) ; 

break; 

} 



15 



20 ) ; 



25 ) ) 



30 



35 



case eFieldType_String : 

if( pAccessor->GetFieldValue ( fieldID, sValue 



if ( 0 == : :_tcslen(sVal;:e.c_str 0 ) ) 
continue; 

univRec. insert ( fieldID, sValue . c_str ( ) 

) 

break; 

case eFieldType_DATE; 

if( pAccessor->GetFieldValue ( fieldID, dtValue 

univRec . insert ( fieldID, dtValue ); 

break; 

case eFieldType_DWORD: 

if( pAcces-or- oGetFieldValue ( fieldID, lvalue ) 

univRec . insert ( fieldID, lvalue ); 

break; 

case eFieldType_Couble : 

if ( pAccessor->GetFieldValue ( fieldID, dValue ) 

univRec. insert ■; fieldID, dValue ); 

break; 



} 

40 

HRESULT CBa.TeAOSTableOCI: :InsertRecord( Mappinglterr, theMap [ ) , int 

num?] f>l d.T, CDataAccessor *plnsertltein, CFl ItemUniversal *pUnivItem, bool 

bForceCreate i 
{ 

bool bHasData = SetRecordFields i theMap, numFields, pinsertltem, 
45 pUnivItem ) ; 

if( bHasData || bForceCreate ) 

{ 

pInsertItem->InsertRow (0) ; 
pInsertItem->Exec ( ) ; 

50 } 

return S_OK; 

) 

/* 

55 * Function: SetRecordFields 
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* Description: Kap fields from an (JniversalReccrd foriTiat into an Oracle 
database record (pinsertltem) 
*/ 

bool CBaseACSTableOCI : : SetRecordFields ! Mappingltem theKap ;] i int 
numf'ields, CDataAccessor *plnsertltem, CFlItemUniversal *pUnivItem ) 
( 

bool bHasData = false; 
CUniverselField field; 

fori int inx=C; inx<nu!nFields ; inx++ ) 
( 

enurtiFieldTag fieldID = -het-Sap | inx | .n_universal FieldlD; 

BOOL bExists = pUnivIteir.->m_record. Find ; fieldlO, field ); 

if( bSxists ) 
( 

bHasDat= = true; 
if{ field. IsBlobO ) 
I 

string blob = f ield . getBlob ( ) ; 
LPCTSTR szEmailAddr = 
GetAddressFromRecipients ( (FIRECIPIEKTS* ) blob. c_str ( ) ) ; 

if( szEmailAddr SS *szEmail.!iddr != NULL ) 
pIn3ertItem->3etFielcVaiue ( f ieldID, 

(string) szEnailAddr ); 

else 
1 

bHasData = false; 
continue ; 

) 

else if{ field . isString i ) ) 
{ 

string sValue = field. getString 0 ; 
if( ! sValue. empty ( ) ) 

pInsertIten->3etFielQValue ( f ieldID, 

) 

else if( field . isLong ( ) i 
{ 

LONG nValue = f ield . getLong ( ) ; 
pInsertItem->SetFieldVal>:e ( f ieldID, nValue) ; 

) 

else if( field. isDate 0 ) 
I 

D.z^TE dValue - field. getDate C ; 
if { dVaiue ) 

pInsertItem->SetFieldValue ! f ieldID, 



sValue ) ; 



dValue ) ; 



) // if( bExists ) 

) /,/ For all fields 

returr. bHasData; 

I 



[0138] While the above-identified code is specific to, for example, an Oracie database, one of average shcili in the art 
will readily recognize that the technique utilized above may be adapted to other types of databases containing records 
and fields of Interest. In the above code examples, all fields which are mapped from a particular application are mapped 
to fields In the master mapping file. 
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Management Server 

[0139] In order to provide security and identification of particuiar users in an internet-Implemented synchronization 
system, a management server may be provided in the system of the present invention. The management server Is a 

5 centralized server which controls behavior and characteristics of the entire networi<of device engines across ali users. 
[0140] Figure 1 4shows the general representation of how a management server 1410 Integrates Itself Into the system 
of the present Invention. Shown In Figure 14 Is an exemplary device engine 1450 which has HTTP links to both a 
management server 1410, a storage server 1415, and a generic FTP server 1420. As wlil be discussed hereinafter 
with reference to the process of the present invention, and the specific Implementation of the data below shown In 

10 Figures 15-17, the management server interacts with the device engine to control authorized access to information on 
the storage server, or a generic FTP server 1420,1425 to access device-specific Information storage 1430 in accord- 
ance with the system of the present Invention. This ailows any device coupling to the internet to have access to man- 
agement protocols and to retain user information across ail platforms which the data which is being synched by the 
system of the present invention must access. 

is [0141] The management server communicates using hypertext transfer protocol (HTTP) which may be implemented 
with a secure sockets layer (SSL) to ensure security. 

[0142] In particular, the management server supports an authentication interface that requires each device engine 
to authenticate with the management server before performing synchronization. Certain storage server implementa- 
tions may utilize locking semantics to control read and write access to storage for multiple device engines. For example. 
20 in a generic FTP request, if two device engines attempt to connect to the same data at the same time, there must be 
some form of ioci<ing control to prevent device engines accessing the same data at the same time, in this instance, 
the management server controls the device engine acquisition, renewal, and releasing of iocics against data stored In 
the networi<. 

[0143] Each device engine Is uniquely identified and tracked by the management server. This ailows for tailoring 
25 behavior between the management server and specific types of storage systems and device engine components, Ail 
device engine components are tagged and version stamped for management via the management server, 
[0144] Device actions can request updated copies of Individual device engine components, pemiltting self-update 
and configuration of device engine systems. This permits minimal download designs for device engines that are on 
low bandwidth connections enabling the device engines to download additional required components at a later time. 
30 [0145] In a further aspect of the system, a value added component may be provided where the management server 
can support client's advertising mechanisms, enabling the dispiay of banner or similar advertising on a device engine 
system without the need for a web browser Cycling of advertisements, statistic collection, and the like, are managed 
via management server protocols. Online purchase and subscription mechanisms are also supported using the man- 
agement server protocol. 

35 [0146] The management server further supports the accounting, sign-up registration, device edition, storage server 
selection, and similar functions for each user in the system, in one embodiment, the management server may retain 
password and encryption infonnation for a given user account. In a second embodiment, such infonnatlon Is not re- 
tained. The second embodiment provides the advantage that users may feel more secure If the malntainer of the 
management server is not in possession of the password to access data In the user's account. 

40 [0147] Further Information with respect to the management server and the data flow from the management server 
to other components of the system of the present invention will become apparent with respect to the discussion of the 
process flow and data flow diagrams In Figures 15-17. 

[0148] Figure 17 shows a general depiction of the data flow and the functional specification of the management 

server utilized in accordance with the present Invention, 
45 [0149] As shown in Figure 17, foliowing a welcome request 1710, a user Is allowed to sign out which enables an add 
user module 1712, and subsequently enables an add device module 1714. If sign-up is not requested, Information may 
be provided via module 1 71 8, 

[0150] As indicated In Figure 1 7, the add user module 1 71 2 adds user records to the user In device database 1 750. 
Additionally, the add device module 1 71 4 adds users and devices to the user device database 1 750. A device list 1 720, 

50 and a device engine download and update database 1722, provide selection data for the add device module 1714, 
The account authentication module 1724 receives Input both directly from a user log-In from the welcome screen at 
1710 and from the add device module 1714. 

[0151] Once an account Is authenticated and confirmed, the administrator of the system of the present invention 
having a private data store at 1 770 may choose to provide a web desktop 1 754 which allows access to a user's records 
55 such as file 1756, e-mali 1758, calendar 1760, contacts 1762, notes 1764, and tasks 1766. The information will be 
culled from a provider database 1752 which wlil be synched In accordance with the system of the present invention 

as previously described. In essence, the provider database 1752 accesses data from the device engines 1780, which 
include, as discussed above, the storage server, each individual device engine 1 785, and a settings database 1 787. 
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[0152] Other portions of the management server include the locking modules for beginning a sync 1732, continuing 
a sync 1734, and ending a sync 1736, and for updating user information including modifying a user 1742, adding 
devices 1744, removing devices 1746, and modifying devices 1748. 

s Storage Server 

[0153] Shown in Figure 14 is the storage server 1415. While storage server 1415 may include a generic storage 
model accessible through any number of standard intemet protocols, in accordance with thepresent invention, a flexible 
storage architecture is provided that permits various standard implementations of the system of the present invention. 

10 This allows deployment of networi< services without installation of new server applications and can be responsible for 
communicating change information between multiple device engines In a consistent fashion. 
[0154] One or more storage servers 1415 maybe used to communicate transaction amongst a collection of devices. 
Each user's personal information network Is represented by a unique account within its own data package storage 
section. The storage server 141 5 maintains persistent store collection of data packages which Is, at a minimum, enough 

is data packages to be capable of synchronizing the most out-of-date system in a user's given infonnation network or 
add information to new devices which are provided in the network. Additional data packages can be maintained to 
permit rollback of previous versions of information. The storage server can automatically dispose of older data package 
storage and can support aging of an inactive accounts. 

[0155] Each storage server 1415 may be implemented using a variety of Implementations including a standard FTP 
20 server for any operating system platform. The storage server can be implemented using HTTP protocols for increased 
efficiency and firewall avoidance. The storage server may be implemented using techniques for local storage such as 
database access or single file storage of a user's entire file system tree. The storage server 1 41 5 may utilize the stored 
foreign protocol model for moving copies of data packages to other storage servers in the system. In one embodiment, 
the storage server can allow tunneling of information using an alternative protocol to other storage servers In cases 
25 where firewall prevents originating protocol. For example, a storage server can relay an FTP traffic inside an HTTP 
protocol. Storage servers may include their own locking semantics to arbitrate multiple device engine access to the 
same server without the need for a separate management server. Each device engine can access only a specific user's 
data package storage area even though the storage server 1415 may maintain a larger number of data packages 
across a large number of users. This allows for increased scaling when the storage server is implemented using file 
30 system techniques. 

[0156] In one aspect, the storage server is implemented using standard FTP or HTTP connections for each operation, 
HTTP Is composed of request response pairs. All requests are supposed to be posting commands. Parameters can 
be set In the form known as "appiication/X-WWW-form-URLENCODED". The encoding is specified as in RFC1866, 
Functions for the storage server include testing if the storage server can reach other users which will retrieve a simple 
35 text string, a "gef command which transfers the contents of a file as in a binary stream of byes; a put command as a 
binary stream of data to the storage server, a directory listing command, a remove command, a rename command, an 
exist command, and the like. 

Pull Synchronization 

40 

[0157] Figure 15 represents a "pull" synchronization process in accordance with the present invention. Both the pull 
synchronization illustrated in Figure 15 and the push synchronization illustrated in Figure 16 are done from the per- 
spective of the device engine. 

[0158] A pull synchronization as illustrated in Figure 15 Is always performed prior to a push synchronization. This 
45 allows the device engine to know whether synchronization of its own data is necessary, 

[0159] Each device has its own triggering mechanism for initiating synchronization. Some devices, such as Windows 
clients and Palm® pilots are triggered manually when the user presses a "sync" button. Other devices, such as a 
cellular telephone, may be triggered automatically after another device completes a sync. Regular, time-based triggers 
are supported as well. A web-based application portal will sync when a user logs into the website security authorization 
50 mechanism , and may optionally sync on a log-out of the user or on the session time-out, but only if the user has changed 
data during the session, 

[0160] For each sync, the triggering event specifies which application types are to sync for the device. This enables 
a triggering event to trigger only a sync for a particular application type. The management server can specify that no 
sync is needed for a particular type of application to minimize traffic to the storage server. Syncs may be triggered via 
55 an HTTP requestto the server. This request holds infonnation about which device to sync and the user log-In Infonnation 
Is bounced to the management server for authorization and validation. Syncs may be triggered by sending an HTTP 
requestto the server and passing the authentication information In the data portion of the requestto the management 
server. Each device may include a servlet that is responsible for retrieving the request and ensuring its proper format 
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before passing the synchronization request on to the server. 

[0161] The device name and device ciass uniqueiy identify a particular device type that is being synchronized, and 
is contained in the management server. Each user has one or more device entries in the management server author- 
ization records and each device name is unique for this user's space. For example, if a user has five devices with his 

5 or her own personal Identification number, there will be five authorization records. There may be two Windows devices, 
two different Palm® devices and a web service portai, each having their own personal identification number 
[0162] As shown in Figure 15, the puil synchronization process starts at an idle state 1405 when the triggering event, 
described above, triggers a synchronization request. The synchronization request is conflnned at 1410 and If the re- 
quest is verified, a connection Is made to the storage server at step 1415. Once a connection is established, the 

10 connection to the management server Is made at step 1420 to authenticate the user identification via the management 
server. If authentication Is successful, the management server may initiate a management server iocl< on the storage 
server so that no conflicting device engines may couple to the same data at the same time. A failure at any of the steps 
1410-1425 will return the system to its idie state 1405. Once the engine server lock Is acquired, the storage server will 
be checked to determine whether a new version of the data exists on the storage server at step 1430. If no new version 

is exists, the synchronization process ends. 

[0163] If a new version of the data exists, the device engine wiil retrieve the difference Infonnatlon at step 1 435 "to 
get A," 

[0164] Once a A Is retrieved, conflicts are resolved at step 1450. The resolve conflicts step allows a user to resolve 
conflicts to multiple types of data which have been changed on both the server portion of the device and in the local data. 

20 [0165] Once the conflicts have been resolved at step 1450, the A's are applied at step 1455. The apply A step 1455 
aliows for fliters and mappings to be accounted for on the iocal device engine side of the system. As shown at steps 
1460, 1465, 1470, and 1475, the A may Inciude updates at the Item levei 1460, appilcation levei 1465, device ievel 
1470, or network levei 1475. In each of the aforementioned steps, a loop back to the A retrieval step 1435 Is provided. 
When no further A's are available, the management server lock is released at step 1440. 

25 [0166] The foregoing description of a puil synchronization is further described in the following pseudo-code: 
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*SyinbolicSyncEngine : :Sync 

Download Remote File System 

For each Symbolic app ir. the file system's list of symbolic apps 
CFDESymbolicSyncEngine : : SyncSinibolicApp 

Create a structured del-a object — CStructuredDelta 

de]ta (...) 

Compare Iccal and remote versions cf deltas SODs), 

if not the same then 

while localVersion != remoteVersion 

download remote version 

// apply delta (change log) 
delta .ApplyChangeLcg 
// See details below 

increment local version 

end while 

else 

no-hing to do 

end if 

if any local items (change logs) are unsent then 

delta->ApplyUnsentItems (Reads the changes [JCL 

where applied?] 

e-d if 

// Generate a nav; c;".dr.ge log for the device: 
delta->delta.GenerateChangeLcg ( . . . strChangeLogFile 
. . . ) // See details below 

FTP it back up to Storage Server 

Update the local version number 

end // SymbolicSyncEngine : ; SyncSymbolicApp 

end // CFDESjinbolicSyncEngine: :Sync 

CStructuredDelta : : ApplyChangeLcg 

Set up m_pAppObj; // IFAO pointer 

Set up rri_pAOS; // lAOS pointer 

0-her set up (statistics, time to complete, etc.) 

Read the change log and . . . 

ApplyChangeListTcAOS (f IChanges) 
for each itme in list 

ApplyltemToAOS // (Does 
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n_pAOS. . . AddRecord/UpdateRecord/DeleteRecordj 
end for 

end // ApplyChangeListToAOS 

If net Going a full sync, also add changes from this file to aoply 
these to m_FlChanges 

end //CStruc-uredDelta: : ApplyChangeLog 



est ructuredDel ta : : Genera teChangeLog 

Set up ir._pAppObj; // IFAO pointer 

Set up ir._pAOS; // lAOS pointer 

Other set up (statistics, time to complete, etc.) 

// Set up m_deviceChang9S by call to: 
CStructuredDelta : ; CreateDeviceChangeList 

Create a CFl:tem* pitera 

/'/ Iterate FAO modifications: 
for (in_pAppObj->GetFirsLModified (pitera) , 
n_pAppObj->GetNextModif ied (pitem) ) 

cast piterr. to — > CFlItenUniversal* pUniltem 

// Do cer-ain things based on whether the operation is 
an add, delete, or update. 

// Then in each case, call: 

CStructuredDelta : :GetMatchingItemFroiiiAOS 

// First get by FlID 
m_pAOS - >GetRecordByFl I D 

// See if we have an ",npID, if so: 
m_pA0S->GetRecordByApp:3 



//If we can build search l<ey on it 
iterate m_pAOS->GetFirstMatchingRecord / 

in_pAOS->GetNextMatchingRecord 

end // CStructuredDelta: :GetMatchingItemFrcmAOS 

end for 

end // CStructuredDelta: : CreateDeviceChangeList 

if m_deviceChanges is net empty 

// reconcile (compare) cr.ance lists while writing to AOS 
CStructuredDelta : : ReconcileChangeLists 

For each item in m_deviceChanges . . . 

If we can find it in m_FlChanges 

Reconcile the device item and the fl 

it am 

end if 

ApplyltemToAOS // (Does 
m_pAOS. . .AddRecord/UpdateRecord/DeleteRecorc) 
end for 

end // CStructuredDelta : :ReconcileChangeLists 
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// Create a new change leg (Fl delta package) 
AppIyChangeListToFl (n_deviceChanges) 
rr._deviceChange . Store 

// Fires off its own whole world, see 

FlItemLisL.cpp 

end /'/ n'_deviceChange . Store 
end // flpplyCr.angeListToFl (m_deviceChanges) 
report stats 

end if 

// Switch ISyncMode) 
If SyncMode full 

ApplyAOSToDevice 

iterate m_pAOS->GetFirstRecord. . .m_pAOS->GetNextRecord 
Add or update the corresponding FAO record. 
(Note. Never delete based on what's in AOS, apparently), 
end // ApplyAOSToDevied 

else 

ApplyChangeLisiToDevice (in_f IChanges) ; 
End // CStructuredDelta: :GenerateChangeLog 



25 Push Synchronization 

[0167] Figure 1 6 shows a push synchronization in accordance with the system and method of the present invention. 
Beginning at idie state 1505, a synchronization event occurs and If confirmed at step 1510, A's are checl<ed at step 
1515. Depending on which type of changes occurred, a network A 1520, device A 1525, iocatlon A 1530, or Item A 
30 1535 will be created. 

[0168] Once the A's for a given application have been created, the method of the present invention continues at step 
1540, which enables a connection to a storage server. Upon connection to the storage server, a further connection to 
management server 1 545 wlii occur to authenticate the user in the system. Failure at any of the aforementioned points 
will result In returning to Idle state 1505. Upon authentication, a management server lock Is enabled to ensure that 
35 multiple device engines do not connect to the same data at the same time. 

[0169] Once a lock Is acquired at step 1555, A's are uploaded to the system. As shown, this may include uploading 
an item A 1575, an application A 1570, uploading a device A 1565, or a network A 1560. Once A's have been uploaded 
to the server, management lock server 1 580 Is released, and the connection to the storage server Is terminated at step 
1585. 

40 [0170] It should be recognized that such a push synchronization need not occur directly to a server, but may occur 
directly to a second device engine In accordance with the depiction of the multiple embodiments of the invention in 
Figures 1-7. 

Data Package Specification 

45 

[0171] Once Information is provided into the universal data format, the device engine organizes the format into a 
data package. Each data package thus includes a description of changes to any and ail Information for particular 
application, and a collection of data packages describes changes across all device engines including ail different types 
of data. With encoding and compression, data packages can become very compact to minimize bandwidth and storage 
so requirements across the system of the present Invention 

[0172] In one particular aspect of the present Invention, encoding of the data packages may be provided in a stream- 
ing format to allow processing by the device engines with minimal storage and memory configuration at the device 
engine level. 

[0173] The device engine can read the stream and detennlne which records from which applications it needs to 
55 update the particular Information present on the system on which it resides. 

[0174] Data packages can be provided In a binary data format. This allows data packages to encode changes to 

non-appilcatlon data at a bite level. Hence, if a single bit on a system changes, the system of the present Invention 
allows synchronization of that bit on another system. Changes are described as a sequence of bite-level change op- 
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erations. One such encoding is using a sequence of insert and copy operations. Insert and copy operations generally 
define a particuiar "insertion" of a number of bites from a source flie, then how many bites of a changed source flie 
must be inserted to a particuiar flie, then how many bites to insert from a particular new file, with a differencing engine 
taking the bites In the stream and inserting them Into the new file to create the new version of the file. 

5 [0175] As will be readily understood by one of average sklil In the art, this allows a user to, for example, change a 
binary flie such as a word processing document or other type of attachment, and synchronize such an attachment at 
the binary level. Specifically, If onefon/vards an e-mail of a word document to a second Individual, the second individual 
modifies it and wishes to return this document with modifications to the first Indlvlduai, because the first Individual has 
the original flie on his system, if both systems are enabled in the system of the present Invention, the second system 

10 need only send the changes or the difference information back to the first system in order for the first system to recon- 
struct the document on the second system using this change data to create the document as intended by the second 
user. 

[0176] Multiple caching of both the generation and application of data packages can be utilized to deal with commu- 
nication Issues In accordance with the system of the present Invention, itshouid be further recognized that data pack- 
15 ages can be merged into larger meta-data packages. Such meta-data information, such as the organization of muitipie 
device packages, may be encoded Into a larger system package. Each system package is essentlaily an encoded 

sequence of data packages. 

[0177] Figure 1 2 shows the general format of the data package and universal data format an object stream hierarchy 
used in accordance with the present Invention, With reference to Figures 11 and 12, one will note that each Item in a 

20 particular application data structure will have a particuiar classification, such as a flie, folder, contact, e-mail, calendar, 
etc. as shown in Figure 13. The universai data structure contains a mapped Item fieid for each type of data possibie 
from each appilcatlon supported by the system. iHence a "master" ilst of every data fieid mapping possible will contain 
a iarge number of Items. Each application object requires a subset of such fields. One exception Is an application object 
used for a Web portal appiication which provides access to ail information availabie on ail devices, inciuding other Web 

25 portals. 

[0178] Particular examples of item fields 1260 which may be included for any given item 1250 are shown In Figure 
13. These exemplary Item objects may, for exampie, be from an aiiocatlon such as Microsoft Outlook. Outlook allows 
for note items 1310, e-mail Items 1320, task items 1330, caiendar Items 1340, bookmark items 1350, file items 1360, 
channei items 1370, folder items 1380, and contact Items 1390, ali of which havefieids such as those represented in 
30 Figure 13. 

[0179] The data format also contains foider information 1240 which aliows the ciasslflcatlon of items and conse- 
quently their associated item fields into particular categories. 

[0180] Appilcatlon objects 1230 include Information onthetypesof applications from which information in the stream 
is Included. Device objects 1220 inciude information on the origin type of device which the information is originating 
35 from. Network objects 1210 Inciude information on a user ievei to define that the Information in the data stream Is 
coming from a particuiar user 

[0181] As detailed above, each appilcatlon object supports a foider store interface that pennlts management of col- 
lections of information on a folder level, and permits management of folder hierarchies of information. The application 
object also includes an Item Interface that permits management of individual Information entries such as records or 
40 files or components of Information entries such as fieids within records. Each application object further supports an 
interface for detection of a vendor application. 

[0182] A DataPack essentlaliy contains a sequence of transactions describing changes to infonnatlon. This Informa- 
tion can span two basic types: structured or application data, and unstructured or binary file data. 
[01 83] Transactions are encoded using an efficient stream i ng to rmat with tags to represent the actual content objects. 
45 This technique permits the continuous extension of the DataPack format as new content Is supported. 

[0184] The general architecture of the package provides for transactions, appilcatlon data, file data, files, objects 
and Identifiers to be carried in the data package. Generaily, transactions, appilcatlon data, file data, and flies have 
previously been described. 

[0185] The first portion of the data package wlil be the data package identifier. Each transaction has a basic archl- 

50 lecture of objects and operations. Each piece of content is referred to as an object and is uniquely represented with a 
Universally Unique identifier (UUID). Objects typically are represented by a dynamically generated UUiD, but more 
common objects are represented by static UUIDs. The following static UUiDs are defined: 
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UUID_Genei:icDefault Folder 
UUID_DefaultCor-tact Folder 
UUID_DsfaultInboxFolder 
5 (JUID_DefaultOuti;oxFolder 

UniD_Default jraftsFolder 
UUID_DefaultTrashFGlder 
UUID_DefaultSen::Folder 
UUIDDefaultCalendarFolder 
UUID_DefaultTas:<Folder 
UUID_DefaultNoteFolder 
UUID_Default JournalFolcer 
UUID_Dsfa-jltFavcriteFolder 
ULiID_DefajltCoo:-:ipFolder 
UUlD_Default;4is;.ory Folder 
U'JID_DefajltChannelFclcer 
UUID_DefaultFileFolder 
U"JID_DefaultCallFolder 

[0186] Each UUID has a unique 128 bit value which may be assigned by the system provider. 
[0187] Transactions are broken down into manageable blocks in the form of individual files. These files are then 
20 optionally compressed and encrypted and prefixed with appropriate headers. Transactions are grouped into specific 
files based on the following rules: 

• Transactions related to account infonnation are grouped Into a DataPacl< file. 

• Transactions related to a specific data class are grouped into a DataPack fiie. 

25 • Transactions referring to binary data are grouped into separate DataPack flies for each fiie object. 

[0188] A DataPack file is identified using specific rules based on the file name. The file name is of the form "UUID. 
VER"whereUUiDls the identifier forthe specific object and VER Is the transaction version number. The version number 
is of the form "D0001 " with additional digits used for large version numbers. The "DOOO" value may be reserved for the 

30 base version for the object. 

[0189] The UUiD forthe user account is generated by the Management Server (MS). The MS also maintains a current 
table of UUiD values and version numbers that provides the root structure for understanding the DataPack files within 
a user account. The MS aiso provides necessary locking semantics needed to maintain consistency when multiple 
device engines attempt to synchronize. 

35 [0190] All DataPacks are prefixed with a standardized header that provides basic content infonnation regarding the 
DataPack, Compression and encryption headers follow the DataPack header if needed. 

[0191] The data package header Information will include version signature, applied versloning Information, content 

type, A engine type, compression type, encryption type, appiied size, encrypted size, compressed size, raw data size, 
and other data useful for the device engine in decrypting the data stream to provide the data into a format usabie for 
40 the application. 

[0192] The header may optimally have the format: 



Type 


Bytes 


Version 


4 


Signature 


4 


AppliedVersion 


8 


ContentType 


4 


DeitaType 


4 


CompressionType 


4 


EncryptionType 


4 


AppliedSize 


4 


EncryptedSize 


4 


CompressedSize 


4 
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(continued) 



Type 


Bytes 


RawSize 


4 


Reserved 


TBD 



[0193] The following ContentType values are pemnissible: 



Field 


Comment 


DP_CONTENT_RAW 


Raw 


DP_CONTENT_GOMPRESSED 


Compressed 


DP_CONTENT_ENCRYPTED 


Encrypted 



[0194] Tlie DeltaType encodes tlie type of binary file differencing used. Tfie following DeltaType values are permis- 
sible using DataPacl<ageDeltaType: 



Field 


Comment 


PackageDeltaTypeUninitialized 


Uninitialized 


PackageDeltaTypeRawData 


Raw binary data 


PackageDeltaTypeDeltaXDelta 


Xdelta binary difference 


PackageDeltaTypeDeltaBDIff 


Bdiff binary difference 



[0195] The compression typespeclfleswhethertheDataPack has been compressed. A DataPackcompresslon head- 
er follows the DataPack header if a compression type Is specified. The following CompressionType values are pemnis- 
sible using DataPackageCompresslonType: 



Field 


Comment 


PackageCompresslonTypeUninltialized 


Uninitialized 


Pacl<agcComprcssionTypcNonc 


None 


PackageCompressionTypePK 


PKZip format 


PackageCompresslonTypeLZS 


LZS format 



[0196] The encryption type specifies whether the DataPack has been encrypted, A DataPack encryption header 
follows the DataPack header if an encryption type is specified. The following EncryptlonType values are permissible 
using DataPackageEncryptlonType: 



Field 


Comment 


PackageEncryptionTypeUninitialized 


Uninitialized 


PackageEncryptlonTypeNone 


None 


PackageEncryptlonTypeXORTest 


XOR masked data 


PackageEncryptionTypeBlowFish 


Blowfish 


PackageEncryptlonTypeTwoFish 


Twoflsh 



[0197] All DataPack compression headers are encoded using the following format: 



Field 


Size (bytes) 


Comment 


Size 


4 


Size of data Including this header 



37 



EP1 130 511 A2 

(continued) 



Field 


Size (bytes) 


Comment 


Version 


4 


Version (1) 


Signature 


4 


Signature (4271) 


HeaderType 


4 


Header type (HeaderTypeCompression) 


Reserved 


12 


Reserved 


DecompressedSize 


4 


Decompressed size 


Reserved 


50 


Reserved 


Reserved 


12 


Reserved 



[0198] The foiiowing IHeaderType values are permissible using DataPaci<ageHeaderType: 



Field 


Comment 


i-leaderTypeUninitlalized 


Uninitialized 


HeaderTypeEncryption 


Encryption header 


HeaderTypeCompression 


Compression header 


HeaderTypeRaw 


Raw header 



[0199] All DataPack encryption headers are encoded using the following fonnat: 



Field 


Size (bytes) 


Comment 


Size 


4 


Size of data Including this header 


Version 


4 


Version (6) 


Signature 


4 


Signature (4270) 


HeaderType 


4 


Header type (HeaderTypeEncryption) 


Resen/ed 


12 


Resen/ed 


DecryptedSize 


4 


Decrypted size 


InitValue 


16 


TBD 


Key Length 


4 


TBD 


ClearTextKeyBits 


4 


TBD 


Salt 


4 


TBD 


PadBytes 


4 


TBD 


HMAC 


20 


TBD 


Reserved 


12 


Resen/ed 



[0200] The data package transaction format may take a number of forms. One example is the following: 

50 
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DataPack transaction fornnst - header - info - objects and operations 
Diagram 

5 transaction ::= xileData I Header + InfcList + TransactionList 

fileData::= raw binary file data i binary difference data 

Header : := ID + DataPackiD + DataPackVersion 
IC : := FUSE 
10 DstaPackIC : := CLOG 

InfoList :;= FieldList 



Operation 

15 Iteirlnfo : 

ItemType : 
IteniFlags 



20 



FieldDataType 
i'ieldDatcLen 
25 FieldDatEDats 



TransactionList : ;= Operation + [Itenlnfo + [FieldList] 1 
:= see table below 

= ItemType + ItemFlags + EntrylD + ParentEntrylD 
= sane as anumltemType 
: = same as enumFlItemFlags 

Er.trylD ■. := UUID 
ParentEntrylD : := UUID 

UUID : ;= 128-bit UUID as defined by standard 

FieldList ::= {FieldTag + FieldData} + ListEnd 
FieldTag same as envanFieldTag 

FieldData : := FieldOataType + IFieldDataLen + [FielcDataData] ] 
= see below 

length as required by FieldDataType 
= data as required by FieldDataType 
ListEnd : := DWORD (0) 



[0201] The following Operation values are permissible using the Operation class: 

30 



Field 


Comment 


cINop 


None 


clAdd 


Add 


cIDeiete 


Delete 


cIChange 


Change 


cli\/love 


Move 


cIRename 


Rename 


clForceChange 


Force change without conflict 



[0202] The following FieldDataType values are permissible using cIDataType: 



Field 


Comment 


cllnvalidTypc 


TBD 


cIString 


Unicode String bytes with a 32-bit length prefix 


cISlringS 


Unicode String bytes with an 8-bit length prefix 


clString16 


Unicode String bytes with a 1 B-bit length prefix 


clEmpty String 


TBD 


clBiob 


32-blt length followed by a byte stream 


clBiobS 


8-bit length followed by a byte stream 


clBiobIG 


16-blt length followed by a byte stream 
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(continued) 



Field 


Comment 


clEmptyBlob 


TBD 


clByte 


8-blt value 


ciShort 


16-bit value 


ciDword 


32-bit value 


clQword 


64-bit value 


cIDate 


DATE type (double) 


cIDouble 


8 byte real 


ci Float 


4 byte real 


clUuld 


16 byte uuid 


clZero 


Zero value 


clOne 


One value 


clUnspecified 


Unspecified value 


cIDefault 


Default value 


cICollection 


Collection with 32-blt length 


cICollectionB 


Collection with 8-bit length 


cICollection 16 


Collection with 1 6-blt length 


clEmptyCollectlon 


Collection with no length 



30 [0203] Data package objects are organized into a hierarchy as follows: 



Account: := DeviceList + DataClassL.i st 
DeviceLisr : := {Device} 

35 

DataClassList: := {DataClassI + ProviderList 



ProviderList: := {Provider) + DataStcreList 
DataStoreList: := (Fclder) + I-emlist 

IteiTList::= -Item) + FieldLisr 
FieldList::= I Field) 



[0204] An account is the root structure, which identifies information about the user's account. It may have exemplary 
field tags (eFieldTag_[NAME]) such as Name, Password, UserName and Version. The FieldTag ItemType value is 
50 specified as ltemType_PIN using enumllemType. 

[0205] A device is a system Identified as part of an account. Examples include PCs, handhelds, Web sites, and so 
on. It may have tags (eFi6ldTag_[Name]) such as: "name" and "type" and Item type values (eDeviceJName]) such as 
Portal, Palm, Windows, CellPhone. 

[0206] A data class Is a grouping of similar information types. Many data classes may be represented for a particular 
55 account. The data class may contain field tags (eFieldTag_[Name]) such as: Name; ItemType; SubType; IsManaged; 
Provider; Filter and Version. 

[0207] The following ItemType values are permissible using enumDataClass (eDataClass_[Name]): 
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5 



10 



15 



Tag 


Description 


UNKNOWN 


1 Inlfnnu/n 


nONTAOT 


f^nntaf^t/firlHrfi*;*; hnnlf 

WUI lldOL/dUUI Coo UUUIV 


EMAIL 


Plpptrnnip mf^il 

1 ICOLIUIIIO IIIClll 


CALENDAR 


Calendar 


TASK 


Tasl</to do 


NOTE 


Note/memo 


JOURNAL 


Journal 


BROWSER 


Web browser favorites, cool<ies, etc. 


FILESET 


Collection of files 


PIN 


Account information 


DEVICE 


Device information 


FILEBODY 


Contents of fiie 



[0208] A Provider Is the application that maintains specific Information within a data class. There can be more than 

one provider for a particular data class. Field tags include: Name, AppObjID, Password, Username and Version. Ex- 
20 amples of provider tags permissible for the provider (eProvider[r\lame]) include: Portal, Palm®, MicrosoftOutlool<®, 
Lotus Organizer, Microsoft Internet Explorer, Microsoft Windows, and so on. 

[0209] Data stores are the containers for storing Infonnatlon within a provider. There can be more than one data 
store for a particular provider. Folders represent structural organization of Information within a data store. Data stores 
are not required to support folders. Tags (eFleldTag_[Name]) supported for each data store Include: Name, ItemType, 
25 IsManagedand OriginalPath, Item types permissible for the data store Include: unknown; Folder: MAPI; Database and 
Store_File. 

[0210] Folders represent structural organization of Information witlnin a data store. Data stores are not required to 
support folders. A folder Is represented by a UUID and may contain any of the following field tags (eFleldTag_[Name]): 
Name; ItemType; IsManaged; FlleAttrlbutes; CreatlonDate; ModiflcatlonDate; AccessDate; Special FolderType. 
30 [021 1] The eFleldTag_ltemType value Is specified as eltemType_FOLDER using enumltemType. 

[0212] Items are Individual Informational components consisting of the actual user data. They may contain field tags 
such as: Name, ItemType, IsManaged, and Version. 

[0213] File Items typically have the following additional field tags (eFleldTag_[Name]): 

35 

F'- 1 ",''-ttribuf,es 

CreationDate 

Modif icationDate 

AccessDate 

FileSize 

FileBody 

DeltaSize 

45 

Hash 



[021 4] Item types may take the format (eltemType_[Name]) and may Include: extended; folder; attachment; contact; 

50 distlist; email; calendar; task; call; note; post; journal; form; script; rule; favorites; subscription; commonjavorltes; 
desktop; common_desktop; startmenu; common_startmenu; channels; cookies; programs; common_programs; star- 
tup; common_startup; sendto; recent; lnternet_cache; lilstory; mapped_drives; printers; docs; doctemplates; fonts; 
window_settings; app_data_folder; app_settings; fileset; pin; device; data_store; file; provider; and data_class; internal. 
[021 5] A field is based on one of a set of base type definitions. All field tag information is encoded using the following 

55 format: 
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Field 


Size (bits) 


Comment 


FieldTag 


16 


Unique tag number 


FieldType 


6 


Field base type 


FieldSubType 


10 


Field sub-type 



[0216] A number of Field types are possible, including: unknown; long; dword; date; string; binary; float; double; 
collection; uniqueid; qword; uuid; file; invalid. LONG is a four byte value encoded in big-endian fcnnat. FieldType 
DWORD is a four byte value encoded in big-endian fomnat. FieldType String is a sequence of Unicode cfiaracters 
followed by a single NULL byte. Interfaces are provided witfi an MBCS value. FieldType Binary is a sequence of bytes. 
FieldType UniquelD is a sequence of bytes as defined by the Universally Unique Identifier (UUID) standard. AO inter- 
faces are provided with a Locally Unique Identifier (LUID) value FieldType QWORD is an eight byte value encoded in 
big-endian format. FieldType File is a UUID tfiat references a separate DataPack containing the file body data. AO 
interfaces are provided with a sequence of Unicode characters followed by a single NULL byte that describes the full 
path name for the file. 

[021 7] Any number of filed sub types are possible. Each of the sub-types includes all of the possible data types from 
all of the supported user applications. As should be well understood, the possibilities In the number of sub-types is 
quite large, and dynamic as each new application supported by the system of the present invention is added. Examples 
of sub-types include: 





SubFleld Description 


Description 


25 


Base 


No sub-type specified 


EmailAddress 


Email address 




EmallAddressLlst 


Email address list 




SearchKey 


Search key 




CategoryList 


Category list 


30 


StrlngLlst 


String list 




DistributionList 


Distribution list 




Gender 


Gender (enumGender) 




TimeZone 


Time zone (enumTimeZone) 




Boolean 


Boolean (TBD) 


35 


NonZeroBool 


Boolean with non-zero value (enumNonZeroBool) 




Priority 


Priority 




Sensitivity 


Sensitivity (enumSensitivity) 




Importance 


Importance (enumlmportance) 


40 


SelectedlVlailingAddr 


Selected mailing address (enumSelectedMailingAddr) 




TaskStatus 


Task status (enumTaskStatus) 




FlagStatus 


Flag status (enumFlagStatus) 




RecurrenceType 


Recurrence type (enumRecurrenceType) 




DayOfWeek 


Day of week (enumDayOfWeek) 


45 


DayOfMonth 


Day of month (1 through 31) 




InstanceOfMonth 


Instance of month (enumlnstanceOfMonth) 




MonthOfYear 


Month of year (enumMonthOfYear) 




BusyStatus 


Busy status (enumBusyStatus) 


50 


AttachmentType 


Attachment type (enumAttachmentType) 


MailBodyType 


Mail body type (enumMailBodyType) 




RGB 


RGB color value 




ManagedState 


Managed state (enumManagedState) 




Faold 


FAO ID for provider 


55 


SpecialFolderType 


Special folder type (enumSpecialFolderType) 




ResponseState 


Response state (TBD) 




ResponseStatus 


Response status (TBD) 
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(continued) 



SubField Description 


Description 


JournalStatus 


Journal status 


PageStyie 


Page style 


PageNumberlWethod 


Page number method 


DelegationState 


Delegation state 


MeetingStatus 


Meeting status 


IVleetinglnvitation 


Meeting invitation 


CaiendarType 


Calendar type 


DateOnly 


Date only 


TimeOnly 


Time only 


PhoneNumber 


Phone number 


URL 


URL 


FiiePath 


File path 


PopWIessageiD 


POP message ID 


IVIilVIEType 


MIME type 


iNVALID 


All values must be below this 



[0218] The aforementioned invention provides a user-centric model of communication to deliver personal information 
via network services. This model accommodates devices that are disconnected from the network, such as the Internet, 
at various times. Personal Information can continue to exist locally rather than Imposing a server-centric model on 
25 existing Information. 

[0219] In accordance witli tlie foregoing, a store and forward information broadcast is utilized. Changes to existing 
information are replicated to an Internet storage server and changes are then retrieved by other devices on the networl< 
at device-specific times. In this manner, direct client communication Is accomplished without requiring one-to-one com- 
munication. While one communication is supported by the system of the present Invention, It need not be required. 

30 [0220] Although the present Invention has been presented In the form of an Internet store and forward broadcast for 
the purposes of synchronizing personal information amongst various types of devices, it will be readily recognized that 
synchronization need not be accomplished as the only application for the aforementioned system, In particular, the 
system can be utilized to efficiently broadcast changes to information in so-called "push" type information applications 
where only portions of the data need to be changed on a client application. For example, in a system where information 

35 such as changes In a stock price need to be broadcast to a plurality of users, a client application Implementing the 
aforementioned technology can be updated by only changing specific portions of the data In the client application 
relative to that particular stock price. This can be done using a smaller bandwidth than has previously been determined 
with other devices. 

[0221] The many objects and advantages of the present invention will be readily apparent to one of average skill in 
40 the art. All such objects and advantages are Intended to be within the scope of the Invention as defined by the written 
description and drawings presented herein. 



Claims 

45 

1 . An system for synchronizing data between a first system and a second system, comprising: 

afirst sync engine on the first system Interfacing with data on the first system to provide difference information: 

50 a data store coupled to network and in communication with the first and second systems; and 

a second sync engine on the second system coupled to receive the difference information from the data store 
via the network, and interfacing with data on the second system to update said data on the second system 
with said difference information. 

55 

2. The apparatus of claim 1 wherein the first system and second system arecoupledto the servervia a private network. 

3. The apparatus of claim 1 wherein the first system and second system are coupled to the server via an internet 
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connection. 

4. The apparatus of claim 1 wherein the difference information is transmitted to the data store by the first sync engine 
and received from the data store from the second sync engine. 

s 

5. The apparatus of ciaim 4 wherein the difference information is transmitted to the data store at a first point in time^ 
and received from the data store at a second, subsequent point in time. 

6. The apparatus of ciaim 1 wherein said second sync engine interfaces with said data on the second system to 
10 provide second difference information to the data store. 

7. The apparatus of claim 6 wherein the first sync engine couples to the data store to retrieve the second difference 
information and Interfaces with the data on the first system to update said data on the first system with said second 
difference information. 

15 

8. The apparatus of ciaim 1 further including a management server coupled to the networic and in communication 
with the first sync engine, the second sync engine and the data store. 

9. The apparatus of claim 8 wherein said management server authorizes access of difference information on the data 
20 store by the first and second sync engines. 

1 0. The apparatus of claim 8 wherein said management server locks access to difference Infonnatlon on the data store 
during communication with the first and the second sync engines. 

25 11. The apparatus of ciaim 1 further including a first device, coupled to the first system via the network, providing said 
data to the first system. 

12. The apparatus of ciaim 11 wherein the first system is a sync server. 

30 1 3. The apparatus of claim 11 wherein said data comprises changes to a previous state of the data, and said difference 
Infonnation comprises said changes in an encoded, universal fonnat. 

14. The apparatus of ciaim 1 wherein said sync engine comprises: 
35 a data Interface; 

a copy of a previous state of said data; and 

a difference transaction generator. 

40 

15. The apparatus of claim 1 wherein said data on said first system comprises application data having a plurality of 
application specific fonnats, and said difference infonnatlon Is provided for each of said formats in a universal 
format to said data store. 

45 16. The apparatus of claim 1 further Including 

a plurality of sync engines on a respective plurality of systems, each of said plurality of engines being coupled 
to receive difference Information from each of said first, second and plurality of sync engines from the data store 
via the network, and each said engine Interfacing with data on the system on which it resides to update said data 
on said system on which It resides with said difference Information, and Interface with data on said system on 

so which It resides to provide difference data Infonnation from the system on which it resides to the data store. 

17. A system, comprising: 

a first device Including at least a first data file and first differencing code having an input and an output coupled 
S5 to a network to receive first device data change transactions, based on said at least one data file, from and 

provide change transactions to, said network; 

a data store coupled to the network having at least one data structure coupled to store change transactions; and 
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a second system including at least a second data file and second differencing code having an Input and an 
output coupied to the networl< to receive said first device data change transactions, and provide second change 
transactions based on said at least second data file to said data store. 

18. The apparatus of cialm 1 7 wherein the first device and second device are coupied to the data store via an Internet 

connection. 

1 9. The apparatus of claim 1 7 wherein the first change transactions are transmitted to the data store by the first device 
at a first point In time and received from the data store by the second device at a second, subsequent point in time. 

20. The apparatus of claim 17 wherein the first differencing code receives second change transactions from the data 
store to and Interfaces with at ieast the first data flie on to update said data with said second change transactions. 

21. The apparatus of ciaim 17 further Including a management server coupied to the networi< and In communication 
is with the first sync engine, the second sync engine and the data store. 

22. The apparatus of claim 17 wherein said management server authorizes access of difference information on the 

data store by the first and second differencing code, 

20 23. The apparatus of claim 1 7 wherein the first device Is a sync server. 
24. The apparatus of claim 1 7 wherein said differencing code comprises: 
an appilcatlon object; 

25 

an appilcatlon object store; and 
a delta engine. 

30 25. A method for synchronizing at least a first and a second resident on a first and a second systems, respectively, 
coupled to the Intemet, respectively comprising: 

determining difference data resulting from changes to the first file on the first system; 

35 transmitting the difference data to a server via the Internet; 

query ing the server from a second system to determine whether difference data exists for flies on the second 
system; 

40 retrieving the difference data to the second system; and 

updating the second file on the second system with the difference data. 

26. The method of ciaim 25 wherein said step of determining comprises: 

45 

comparing a current instance of the first flie to a stored instance of the first file; and 

generating said difference data. 

50 27. The method of ciaim 25 wherein said step of querying comprises: 

coupiing to a management server which provides infonnatlon on a state of said difference data for files on 
the first system and the second system. 

28. The method of claim 25 wherein said step of retrieving comprises: 

55 

coupiing to the management server; 

receiving authorization from the management server to retrieve the difference data; 
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transmitting a request to tiie server for tiie difference data; and 
receiving thie difference data in response to tiie request. 

5 29. The mettnod of claim 28 wherein the management server loclcs the server from receiving furtfier requests for tfie 

difference data during said retrieving step. 

30. The method of claim 25 wherein said step of updating comprises: 

applying the difference data to a stored instance of the second flie on the second system. 

10 

31. An internet synchronization system, comprising 

a storage server having an internet connection; 
15 a first device coupled to the Internet and inciuding a device sync engine; and 

a second device coupied to the internet and including a second device sync engine. 

32. The internet synchronization system of claim 31 further Inciuding: 
20 a management server. 

33. The Intemet synchronization system of claim 32 wherein the storage server and the management server are pro- 
vided In a data center. 

25 34. The Internet synchronization system of claim 31 wherein communications between the first device, the second 
device and the storage server are encoded and compressed. 

35. The Intemet synchronization system of claim 31 wherein data transfer between the first device, the second device 
and the storage server comprises difference transactions. 

30 

36. The internet synchronization system of claim 31 wherein each device includes applications having data in an 
application specif ic format, and wherein communication between the first device, the second device and the storage 
server include changes to said data in an application Independent format. 

35 37. The Internet synchronization system of claim 31 wherein each device sync engine comprises: 

an application object; 

an application object store; and 

40 

a deita engine. 
38. A data synchronization system, comprising: 
45 a sen/er; 

a first system having a plurality of data file types on the system; 

a differencing synchronizer on the first system extracting a first set of differencing data from the data flies on 

so the first system when the data files on the system are changed, outputting the differencing data to the server, 

and retrieving differencing data from the server and applying it to selected data files on the first system; 

at least one second system having a second plurality of data flie types on the second system; and 

55 a differencing synchronizer on the second system extracting the differencing data from the data flies on the 

second system when the data files on the system are changed, outputting the differencing data to the server, 
and retrieving the first set of differencing data from the server and applying it to selected data files on the 
second system. 
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39. The system of claim 38 wherein said systems are coupied to aliow transfer of said difference data between systems. 

40. The system of claim 39 wherein said systems are coupled via the Internet. 

5 41. The system of claim 39 further including a server coupled to each of said first and second systems to receive, 

store, and output said first set and said second set of differencing data. 

42. The data synchronization system of claim 38 wherein said first system is a server and said second system is a 
device capabie of communicating with said server 

10 
15 
20 
25 
30 
35 
40 
45 
SO 
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FIG. 16 
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